GHSA-C9CV-MQ2M-PPP3

Vulnerability from github – Published: 2026-06-16 13:47 – Updated: 2026-06-16 13:47
VLAI
Summary
Nuxt: URL-handling weaknesses in `navigateTo` and `reloadNuxtApp`: SSR open redirect, client-side script execution via the `open` option, and protocol-relative bypass in `reloadNuxtApp`
Details

Summary

Three weaknesses in Nuxt's client-navigation URL handling, all reachable from documented public APIs (navigateTo and reloadNuxtApp):

  1. SSR open redirect in navigateTo via path-normalisation bypass. navigateTo decided whether a target was external by inspecting the raw input with hasProtocol(..., { acceptRelative: true }). Inputs such as /..//evil.com, /.//evil.com, /%2e%2e//evil.com, or /app/..//evil.com slipped past that check because they start with /, but WHATWG URL parsing then normalised them to the protocol-relative pathname //evil.com. The normalised value was written to the Location response header and into the <meta http-equiv="refresh"> body of the SSR redirect page, so a victim's browser would resolve the redirect cross-origin to the attacker's host.

  2. Client-side script execution via navigateTo({ open: ... }). The client-side early-open handler called window.open(toPath, ...) without applying the isScriptProtocol check that gates the normal navigateTo path. A target of javascript:... (or another script-capable scheme) passed to navigateTo(url, { open: { ... } }) therefore executed in the application's origin instead of being rejected.

  3. Open redirect in reloadNuxtApp via protocol-relative bypass. reloadNuxtApp({ path }) rejects script-capable protocols by parsing the path with new URL(path, window.location.href) and checking the resolved protocol against isScriptProtocol. Protocol-relative paths such as //evil.com resolve to the current page's protocol (https:), which passes that check; the value is then assigned to window.location.href, which the browser treats as a cross-origin redirect. This is the same protocol-relative bypass family as (1), in a different sink.

Impact

For (1), the practical risk is phishing or OAuth-code theft against any Nuxt app that forwards user-controlled input (for example a ?next= query parameter on a login route) into navigateTo on the server. The framework documents that navigateTo blocks external hosts unless external: true is passed, so maintainers commonly rely on it as the safe path for post-login redirects.

For (2), any app that passes a user-controlled URL into navigateTo(url, { open: { ... } }) was vulnerable to reflected XSS in the application's first-party origin.

For (3), any app that forwards user-controlled input into reloadNuxtApp({ path }) could be redirected cross-origin for phishing or OAuth-code theft, even on releases that already shipped the isScriptProtocol guard added by #35115.

Patches

Fixed in nuxt@4.4.7 and backported to nuxt@3.21.7. The three sinks are addressed by:

Workarounds

  • For (1): validate redirect targets before passing them to navigateTo, for example reject any input where new URL(target, 'http://localhost').pathname starts with //, or only accept a known allow-list of paths.
  • For (2): reject any user-controlled URL whose protocol is not in an allow-list (typically just http: and https:) before passing it to navigateTo({ open: ... }).
  • For (3): same shape as (1). Reject paths starting with // (or where new URL(path, window.location.href).host !== window.location.host) before passing to reloadNuxtApp({ path }).

References

  • CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
  • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Credits

Reported by Anthropic / Claude as ANT-2026-S08HN6DH through Anthropic's coordinated vulnerability disclosure programme.

The reloadNuxtApp protocol-relative bypass (sink 3) was independently reported by @alcls01111 via GitHub's coordinated disclosure flow (GHSA-w7fp-2cfv-4837), closed as a duplicate of this advisory.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.21.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-601",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T13:47:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThree weaknesses in Nuxt\u0027s client-navigation URL handling, all reachable\nfrom documented public APIs (`navigateTo` and `reloadNuxtApp`):\n\n1. **SSR open redirect in `navigateTo` via path-normalisation bypass.**\n   `navigateTo` decided whether a target was external by inspecting the raw\n   input with `hasProtocol(..., { acceptRelative: true })`. Inputs such as\n   `/..//evil.com`, `/.//evil.com`, `/%2e%2e//evil.com`, or\n   `/app/..//evil.com` slipped past that check because they start with\n   `/`, but WHATWG URL parsing then normalised them to the\n   protocol-relative pathname `//evil.com`. The normalised value was\n   written to the `Location` response header and into the\n   `\u003cmeta http-equiv=\"refresh\"\u003e` body of the SSR redirect page, so a\n   victim\u0027s browser would resolve the redirect cross-origin to the\n   attacker\u0027s host.\n\n2. **Client-side script execution via `navigateTo({ open: ... })`.** The\n   client-side early-open handler called `window.open(toPath, ...)` without\n   applying the `isScriptProtocol` check that gates the normal `navigateTo`\n   path. A target of `javascript:...` (or another script-capable scheme)\n   passed to `navigateTo(url, { open: { ... } })` therefore executed in the\n   application\u0027s origin instead of being rejected.\n\n3. **Open redirect in `reloadNuxtApp` via protocol-relative bypass.**\n   `reloadNuxtApp({ path })` rejects script-capable protocols by parsing\n   the path with `new URL(path, window.location.href)` and checking the\n   resolved `protocol` against `isScriptProtocol`. Protocol-relative paths\n   such as `//evil.com` resolve to the current page\u0027s protocol (`https:`),\n   which passes that check; the value is then assigned to\n   `window.location.href`, which the browser treats as a cross-origin\n   redirect. This is the same protocol-relative bypass family as (1), in\n   a different sink.\n\n### Impact\n\nFor (1), the practical risk is phishing or OAuth-code theft against any\nNuxt app that forwards user-controlled input (for example a `?next=`\nquery parameter on a login route) into `navigateTo` on the server. The\nframework documents that `navigateTo` blocks external hosts unless\n`external: true` is passed, so maintainers commonly rely on it as the\nsafe path for post-login redirects.\n\nFor (2), any app that passes a user-controlled URL into\n`navigateTo(url, { open: { ... } })` was vulnerable to reflected XSS in\nthe application\u0027s first-party origin.\n\nFor (3), any app that forwards user-controlled input into\n`reloadNuxtApp({ path })` could be redirected cross-origin for phishing\nor OAuth-code theft, even on releases that already shipped the\n`isScriptProtocol` guard added by [#35115](https://github.com/nuxt/nuxt/pull/35115).\n\n### Patches\n\nFixed in `nuxt@4.4.7` and backported to `nuxt@3.21.7`. The three sinks\nare addressed by:\n\n- Path-normalisation bypass in `navigateTo`:\n  - 4.x: commit [`2cce6fb0`](https://github.com/nuxt/nuxt/commit/2cce6fb02e621196d56df92e05594e07469b5a6d)\n  - 3.x: commit [`1f2dd5e7`](https://github.com/nuxt/nuxt/commit/1f2dd5e78c77576437138e97671965573c232835)\n- `navigateTo({ open })` script-protocol guard:\n  - 4.x: [#35206](https://github.com/nuxt/nuxt/pull/35206) (commit [`3394716d`](https://github.com/nuxt/nuxt/commit/3394716d4a913cba904b028df5338f2aead50032))\n  - 3.x: commit [`62fc32ed`](https://github.com/nuxt/nuxt/commit/62fc32eddf648b00a3890141e0235d2a222b024d)\n- Protocol-relative bypass in `reloadNuxtApp`:\n  - 4.x: commit [`e447a793`](https://github.com/nuxt/nuxt/commit/e447a793c47766834f7497f8412a76cd56fd8ee1)\n  - 3.x: commit [`6497d99d`](https://github.com/nuxt/nuxt/commit/6497d99dd106254abd089f6a263d7773869a343b)\n\n### Workarounds\n\n- For (1): validate redirect targets before passing them to `navigateTo`,\n  for example reject any input where\n  `new URL(target, \u0027http://localhost\u0027).pathname` starts with `//`, or\n  only accept a known allow-list of paths.\n- For (2): reject any user-controlled URL whose protocol is not in an\n  allow-list (typically just `http:` and `https:`) before passing it to\n  `navigateTo({ open: ... })`.\n- For (3): same shape as (1). Reject paths starting with `//` (or where\n  `new URL(path, window.location.href).host !== window.location.host`)\n  before passing to `reloadNuxtApp({ path })`.\n\n### References\n\n- CWE-601: URL Redirection to Untrusted Site (\u0027Open Redirect\u0027)\n- CWE-79: Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)\n\n### Credits\n\nReported by Anthropic / Claude as `ANT-2026-S08HN6DH` through Anthropic\u0027s\ncoordinated vulnerability disclosure programme.\n\nThe `reloadNuxtApp` protocol-relative bypass (sink 3) was independently\nreported by [@alcls01111](https://github.com/alcls01111) via GitHub\u0027s\ncoordinated disclosure flow (`GHSA-w7fp-2cfv-4837`), closed as a\nduplicate of this advisory.",
  "id": "GHSA-c9cv-mq2m-ppp3",
  "modified": "2026-06-16T13:47:52Z",
  "published": "2026-06-16T13:47:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/security/advisories/GHSA-c9cv-mq2m-ppp3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/pull/35115"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/pull/35206"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/1f2dd5e78c77576437138e97671965573c232835"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/2cce6fb02e621196d56df92e05594e07469b5a6d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/3394716d4a913cba904b028df5338f2aead50032"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/62fc32eddf648b00a3890141e0235d2a222b024d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/6497d99dd106254abd089f6a263d7773869a343b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/e447a793c47766834f7497f8412a76cd56fd8ee1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nuxt/nuxt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Nuxt: URL-handling weaknesses in `navigateTo` and `reloadNuxtApp`: SSR open redirect, client-side script execution via the `open` option, and protocol-relative bypass in `reloadNuxtApp`"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…