GHSA-c9cv-mq2m-ppp3 is a medium-severity (CVSS 6.1) Open Redirect vulnerability in nuxt. O3 Security confirms whether GHSA-c9cv-mq2m-ppp3 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
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`
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-c9cv-mq2m-ppp3.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-c9cv-mq2m-ppp3 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 371,256 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
nuxtnpmDescription
Summary
Three weaknesses in Nuxt's client-navigation URL handling, all reachable
from documented public APIs (navigateTo and reloadNuxtApp):
-
SSR open redirect in
navigateTovia path-normalisation bypass.navigateTodecided whether a target was external by inspecting the raw input withhasProtocol(..., { acceptRelative: true }). Inputs such as/..//evil.com,/.//evil.com,/%2e%2e//evil.com, or/app/..//evil.comslipped 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 theLocationresponse 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. -
Client-side script execution via
navigateTo({ open: ... }). The client-side early-open handler calledwindow.open(toPath, ...)without applying theisScriptProtocolcheck that gates the normalnavigateTopath. A target ofjavascript:...(or another script-capable scheme) passed tonavigateTo(url, { open: { ... } })therefore executed in the application's origin instead of being rejected. -
Open redirect in
reloadNuxtAppvia protocol-relative bypass.reloadNuxtApp({ path })rejects script-capable protocols by parsing the path withnew URL(path, window.location.href)and checking the resolvedprotocolagainstisScriptProtocol. Protocol-relative paths such as//evil.comresolve to the current page's protocol (https:), which passes that check; the value is then assigned towindow.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:
- Path-normalisation bypass in
navigateTo: navigateTo({ open })script-protocol guard:- Protocol-relative bypass in
reloadNuxtApp:
Workarounds
- For (1): validate redirect targets before passing them to
navigateTo, for example reject any input wherenew URL(target, 'http://localhost').pathnamestarts 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:andhttps:) before passing it tonavigateTo({ open: ... }). - For (3): same shape as (1). Reject paths starting with
//(or wherenew URL(path, window.location.href).host !== window.location.host) before passing toreloadNuxtApp({ 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | nuxt | ≥ 4.0.0&&< 4.4.7 | 4.4.7 |
| 📦npm | nuxt | ≥ 3.5.0&&< 3.21.7 | 3.21.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nuxt. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update nuxt to 4.4.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c9cv-mq2m-ppp3 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-c9cv-mq2m-ppp3 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-c9cv-mq2m-ppp3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-c9cv-mq2m-ppp3 in your dependencies?
O3 detects GHSA-c9cv-mq2m-ppp3 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.