Nuxt CVE-2026-56326

Exploitation requires the target Nuxt application to forward user-controlled input - such as a query parameter like ?next=, ?redirect=, or ?return_to= - directly into the navigateTo function during server-side rendering without independent path sanitization. The vulnerability is exclusively triggered in the SSR execution path where navigateTo writes to the HTTP Location header or <meta http-equiv='refresh'> body; purely client-side navigation invocations are not affected by this specific weakness. No authentication is required from the attacker (confirmed by PR:N in the CVSS 4.0 vector), but exploitation requires a victim to follow a crafted link (UI:P). Applications that only pass hardcoded paths to navigateTo, or that apply their own origin-validated allowlist before calling the function, are not exposed. Applications that call navigateTo with external: true explicitly set are not directly protected by that flag, as the check is what was bypassed. The GHSA advisory also notes two related but distinct weaknesses (XSS via the open option and a reloadNuxtApp bypass) that have separate exploitation conditions and are not described by this CVE.

The CVSS 4.0 score of 5.3 with vector AV:N/AC:L/AT:N/PR:N/UI:P reflects a medium-severity, network-exploitable issue requiring passive user interaction (a victim must follow a crafted link), with limited confidentiality and integrity impacts (VC:L/VI:L). The UI:P requirement moderates the raw risk: mass exploitation is constrained by the need for victim interaction, ruling out automated scanning campaigns. No EPSS score was provided in the input, so exploitation probability cannot be quantified numerically. The vulnerability is not in CISA KEV and no public exploit code has been identified, though exploitation requires only a crafted URL and no specialized tooling. The real-world risk is substantially elevated for any Nuxt application that forwards user-controlled redirect parameters (e.g., ?next=, ?redirect=) into navigateTo on the server - a pattern the framework's own documentation normalizes. The OAuth authorization-code theft scenario is the highest-impact outcome: a victim who clicks a login link to a Nuxt application and completes authentication could have their authorization code silently redirected to an attacker's server, resulting in account takeover with no further interaction. The subsequent-system impacts (SC:L/SI:L) in the CVSS 4.0 vector correctly capture this cross-origin spillover. Defenders should weight the trust-model risk above the raw score.

An attacker crafts a phishing email or message containing a login URL for a Nuxt application with a redirect parameter such as ?next=/..//evil.com. When a victim clicks the link and completes authentication, the server-side navigateTo function processes the unvalidated parameter; WHATWG URL parsing normalizes /..//evil.com to //evil.com, and the server issues an HTTP response with Location: //evil.com or a <meta http-equiv='refresh' content='0; url=//evil.com'> tag. The victim's browser follows the redirect to the attacker's site, where if the application uses OAuth, the authorization code appended to the callback URL is delivered directly to the attacker, enabling full account takeover without further interaction. No public exploit code is known to exist, but the attack requires only a crafted URL and a vulnerable application that forwards user input to navigateTo.