CVE-2026-56326

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.

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.

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.

Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.

Kodem intelligence

Fixed in [email protected] and backported to [email protected]. The three sinks
are addressed by:

• Path-normalisation bypass in navigateTo:
  • 4.x: commit 2cce6fb0
  • 3.x: commit 1f2dd5e7
• navigateTo({ open }) script-protocol guard:
  • 4.x: #35206 (commit 3394716d)
  • 3.x: commit 62fc32ed
• Protocol-relative bypass in reloadNuxtApp:
  • 4.x: commit e447a793
  • 3.x: commit 6497d99d

1. What is CVE-2026-56326? CVE-2026-56326 is a medium-severity cross-site scripting (XSS) vulnerability in nuxt (npm), affecting versions >= 4.0.0, < 4.4.7. It is fixed in 4.4.7, 3.21.7. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
2. Which versions of nuxt are affected by CVE-2026-56326? nuxt (npm) versions >= 4.0.0, < 4.4.7 is affected.
3. Is there a fix for CVE-2026-56326? Yes. CVE-2026-56326 is fixed in 4.4.7, 3.21.7. Upgrade to this version or later.
4. Is CVE-2026-56326 exploitable, and should I be worried? Whether CVE-2026-56326 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-56326 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-56326?
   • Upgrade nuxt to 4.4.7 or later
   • Upgrade nuxt to 3.21.7 or later