|
Vulnerabilities
< Back

GHSA-c9cv-mq2m-ppp3

Updated on 16 Jun 2026

Severity

Awaiting Analysis

Details

Links
NISTCIRCLRHELUbuntu

Overview

About vulnerability

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 [email protected] and backported to [email protected]. 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.

Details

Affected product:
cli , nuxt
Affected packages:
nuxt @ 0.10.7 (+59 more)

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 [email protected] and backported to [email protected]. 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.