CVE-2026-56697
MediumCVSS 6.1Exploitation Probability (EPSS)
Low risk8th percentile - higher than 8% of all known CVEs
Summary
Nuxt versions 4.0.0 before 4.4.7 and 3.x before 3.21.7 accept protocol-relative paths such as //evil.com in the reloadNuxtApp function. These paths pass the script-protocol check but resolve to a cross-origin URL against the current page protocol.
Risk Assessment
Attackers can inject paths like //evil.com to redirect users to attacker-controlled hosts, enabling phishing and OAuth authorization-code theft.
Recommendation
It is recommended to update Nuxt to version 4.4.7 or 3.21.7 to mitigate this vulnerability. Additionally, conducting a code audit to identify and eliminate potential security flaws is advisable.
Other vulnerabilities in Nuxt
See all- CVE-2026-120309Low
Nuxt from 4.6.0 before 4.6.2 contains a route parameter confusion vulnerability in getRouterParam and getRouterParams. Attackers can return a parameter value different from the one h3 matched by sending paths containing an encoded question mark (%3F), so authorization checks use the Nuxt helper value while resource selection uses event.context.params.
- CVE-2026-71319Critical
Nuxt before 3.3.1 in development mode exposes an unauthenticated RPC channel over the Vite HMR WebSocket. An attacker who can reach the HMR port can call methods like updateOptions() and openInEditor(), allowing arbitrary program execution on the developer's machine.
- CVE-2026-119201Medium
In Nuxt from 4.6.0 until 4.6.3, the development server stores a generated appSecret in <buildDir>/app-secret (by default .nuxt/app-secret) within a directory allowed by Vite's server.fs configuration. A client with direct HTTP access to an exposed development server can fetch the file, use deriveSecret() to compute derived secrets such as the default useSession password, and forge session cookies accepted by that server. The default localhost binding limits remote exposure, production builds and servers with an explicitly configured appSecret are not affected. This is fixed in version 4.6.3.
- CVE-2026-119200Medium
In Nuxt from 4.6.0 until 4.6.3, Nuxt resolves literal or percent-encoded dot segments before rendering a page while Nitro routing, server/middleware checks, and server route rules evaluate the unresolved path. A request such as /%2e/admin can render app/pages/admin.vue and its server-rendered data while checks keyed to /admin, redirects, or per-route security headers do not apply. API handlers, appMiddleware, Nuxt 3, and Nuxt 4.0.0 through 4.5.x are not affected, and exploitation requires a client that sends dot segments without browser normalization. This is fixed in version 4.6.3.
- CVE-2026-119199Medium
In Nuxt from 3.0.0 until 4.6.3, the development server can expose the Nitro 2 development bundle at <buildDir>/dev/index.mjs through Vite file serving when the server is reachable over HTTP. Nitro inlines private runtimeConfig values resolved at build time into that bundle, including secrets configured in nuxt.config, and Nuxt 4.6.0 and later also inline the generated development appSecret. The default localhost binding limits remote exposure, production builds and Nitro 3 are not affected, and runtime configuration supplied only through NUXT_* environment variables at server startup is not inlined. This is fixed in version 4.6.3.
- CVE-2026-119198Medium
In Nuxt from 4.6.0 until 4.6.3, a client with TCP access to an exposed Nuxt development server can send a nuxt:dev:client-error event over the HMR socket with an absolute file path at the end of its message. The development server reads that file while building the client error report and returns its contents through the error overlay, development error channel, and terminal report, bypassing Vite's server.fs allow list. The default localhost binding limits remote exposure, cross-origin browser requests are rejected, production builds and Nuxt 3 are not affected, and no browser interaction is required. This is fixed in version 4.6.3.
- CVE-2026-114133Medium
Nuxt framework versions 3.13.0 through 4.6.2 contain a vulnerability where the server-island renderer serializes raw useHeadSafe entry input without preserving the safe-input marker, and NuxtIsland later inserts that input into the page head as an ordinary entry. An application passing attacker-controlled data to useHeadSafe in a .server.vue component or one rendered through NuxtIsland can render values normally removed by the allowlist, including event-handler attributes or executable script content, resulting in stored cross-site scripting in the application origin. The issue is fixed in version 4.6.2.
- CVE-2026-114132Medium
In Nuxt prior to 4.6.2, pages are resolved case-insensitively by default while Nitro matches server-side route-rule keys case-sensitively. A request differing only by letter case can render without the intended server rule, skipping redirects, headers, proxy, ssr: false, and noScripts. Applications setting router.options.sensitive: true in nuxt.config are not affected.
- CVE-2026-114131Medium
Nuxt, an open-source web development framework for Vue.js, from 3.11.0 until 3.21.4 and 4.4.4 compares route-rule keys with the raw request path while route resolution decodes dynamic and catch-all parameters. This allows a percent-encoded segment to resolve to a protected page without matching the routeRules entry intended for that path, so appMiddleware can be skipped during server rendering and an unauthenticated requester can receive the gated page and its SSR data.
- CVE-2026-114130Low
In Nuxt before 4.6.0, an incomplete fix for CVE-2026-53722 allows an application with pages disabled to render a script-capable URL through NuxtLink when attacker-controlled input bound to the to attribute is prefixed with an ASCII C0 control character. The no-pages router classifies the value as an internal route before the earlier protocol check and passes it to the rendered anchor href; browsers strip the leading control character and interpret the remaining javascript: URL. This is fixed in version 4.6.0.
Original NVD description (English source)
Nuxt versions 4.0.0 before 4.4.7 and 3.x before 3.21.7 accept protocol-relative paths such as //evil.com in the reloadNuxtApp function; these pass the script-protocol check but resolve to a cross-origin URL against the current page protocol. Attackers can inject paths like //evil.com to redirect users to attacker-controlled hosts, enabling phishing and OAuth authorization-code theft.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

