CVE-2026-71319

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.

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.

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.

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.

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.

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.

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.

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.

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.

Information disclosure vulnerability in Nuxt versions >= 4.4.7 and < 4.5.1, and >= 3.21.7 and < 3.21.10. The Chrome DevTools workspace endpoint in the development server trusts the Host header instead of the peer address, allowing an unauthenticated LAN attacker to retrieve the project's root directory path and a workspace UUID.