EUVD-2026-36420
GHSA-fx6j-w5w5-h468
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (https://github.com/nuxt/nuxt) · only source for this CVE.
CVSS VectorVendor: https://github.com/nuxt/nuxt
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3Blast Radius
ecosystem impact- 2 npm packages depend on nuxt (2 direct, 0 indirect)
Ecosystem-wide dependent count for version 3.4.3.
DescriptionCVE.org
Summary
navigateTo() with external: true generates a server-side HTML redirect body containing a <meta http-equiv="refresh"> tag. The destination URL is only sanitized by replacing " with %22, leaving <, >, &, and ' unencoded. An attacker who can influence the URL passed to navigateTo(url, { external: true }) can break out of the content="…" attribute and inject arbitrary HTML/JavaScript that executes under the application's origin.
This is a different root cause from CVE-2024-34343 (GHSA-vf6r-87q4-2vjf), which addressed javascript: protocol bypass. The issue here is triggered by any valid URL containing >.
Impact
Applications that pass user-controlled input to navigateTo(url, { external: true }) - typically via a ?next= / ?redirect= query parameter used for post-login or "return to" flows - are vulnerable to reflected cross-site scripting. The injected script runs in the context of the application's origin during the server-rendered redirect response, before the meta-refresh fires.
Details
In packages/nuxt/src/app/composables/router.ts, the SSR redirect path builds an HTML response body with only " percent-encoded in the destination URL:
const encodedLoc = location.replace(/"/g, '%22')
nuxtApp.ssrContext!['~renderResponse'] = {
status: sanitizeStatusCode(options?.redirectCode || 302, 302),
body: `<!DOCTYPE html><html><head><meta http-equiv="refresh" content="0; url=${encodedLoc}"></head></html>`,
headers: { location: encodeURL(location, isExternalHost) },
}The Location header is normalised through encodeURL() (which uses the URL constructor and correctly percent-encodes attribute-significant characters). The HTML body uses a narrower sanitiser. That mismatch is the root cause.
Proof of concept
Global middleware that forwards a query parameter to navigateTo:
// middleware/redirect.global.ts
export default defineNuxtRouteMiddleware((to) => {
const next = to.query.next as string | undefined
if (next) {
return navigateTo(next, { external: true })
}
})Request:
GET /?next=https://evil.example/x><img src=x onerror=alert(document.domain)>Response body:
<!DOCTYPE html><html><head><meta http-equiv="refresh" content="0; url=https://evil.example/x><img src=x onerror=alert(document.domain)>"></head></html>The > after evil.example/x terminates the content="…" attribute, and the <img onerror> tag executes JavaScript in the application's origin before any redirect occurs.
Patches
Fixed in nuxt@4.4.6 and nuxt@3.21.6 by #35052. The fix percent-encodes the full set of HTML-attribute-significant characters (&, ", ', <, >) before interpolating the URL into the meta-refresh body
Workarounds
If you can't upgrade immediately, validate user-controlled URLs before passing them to navigateTo(url, { external: true }). At minimum, normalise through new URL(input).toString() and reject inputs containing < or > (a normalised URL with these characters is malformed and safe to refuse).
AnalysisAI
Reflected XSS in Nuxt's navigateTo() function allows remote attackers to inject and execute arbitrary JavaScript in the application's origin during server-side rendering. Applications passing user-controlled input to navigateTo(url, { external: true }) - the common post-login ?next= or ?redirect= redirect pattern - are affected across nuxt versions 3.4.3-3.21.5 and 4.0.0-alpha.1-4.4.5. A full proof-of-concept is published in the GitHub Security Advisory GHSA-fx6j-w5w5-h468; no public exploit identified at time of analysis beyond that PoC, and this CVE does not appear in CISA KEV.
Technical ContextAI
The vulnerability resides in packages/nuxt/src/app/composables/router.ts within the Nuxt.js SSR framework (pkg:npm/nuxt). When navigateTo() is called with external: true during server-side rendering, Nuxt constructs an HTML redirect response body embedding the destination URL in a <meta http-equiv="refresh" content="0; url=..."> tag. Prior to the fix, only the double-quote character was encoded (" → %22), while HTML-attribute-significant characters <, >, &, and ' were passed through unencoded. This contrasts with the Location HTTP header path, which correctly routes through encodeURL() backed by the browser URL constructor and fully percent-encodes these characters. CWE-83 (Improper Neutralization of Script in Attributes in a Web Page) describes this root cause precisely: insufficient output encoding when interpolating untrusted data into an HTML attribute context, enabling attribute boundary breakout. This is a distinct root cause from CVE-2024-34343 (GHSA-vf6r-87q4-2vjf), which blocked javascript: protocol injection but left the HTML encoding gap unaddressed.
RemediationAI
Upgrade to nuxt 3.21.6 (v3 branch) or nuxt 4.4.6 (v4 branch), which resolve this issue by replacing the narrow double-quote-only encoder with a full HTML-attribute encoder covering &, ", ', <, and > - implemented via pull request https://github.com/nuxt/nuxt/pull/35052. If immediate upgrade is not possible, add application-level input validation before any call to navigateTo(url, { external: true }): normalize the input through new URL(input).toString() and reject any value whose normalized form still contains < or >, as a correctly normalized URL never contains these characters raw. This workaround requires modifying every call site that accepts user-controlled redirect targets and may reject unusual but technically valid URLs that contain these characters in fragments - a trade-off that is acceptable given the security benefit. CSP alone is not a reliable compensating control because it cannot universally block inline script execution injected via attribute breakout across all browser versions and configurations.
Share
External POC / Exploit Code
Leaving vuln.today