Nuxt 4.6.3 was released on 27 October 2026, and the Nuxt maintainers published five security advisories the same day. The v4.6.3 release notes list the corresponding fixes. Four of the advisory records, each with a corresponding CVE, entered the reviewed GitHub Advisory Database on 30 October, so none of this is new as of this writing. We checked the sources on 1 November 2026.

The key point first: not every Nuxt site is affected. Two notices concern production page handling under specific conditions. Three concern the development server only and do not affect production builds. A deployed site or preview that mistakenly runs nuxt dev is still within scope for those three, so confirm what each environment actually runs before acting.

Step one: know what you run

Ask your developer or hosting provider for the resolved lockfile versions of nuxt, @nuxt/nitro-server and @nuxt/vite-builder. Also ask whether production serves a built output, and whether any development process is reachable from outside, including preview environments, tunnels, container ports and staging hosts. Read this from deployment configuration and firewall rules, not from scanning tools.

If your project is still on Nuxt 3, note that Nuxt 3 has reached end of life. Two notices below include Nuxt 3 ranges, and the 4.6.3 fix does not reach those versions. Upstream guidance is to move to a supported Nuxt 4 release.

Production page handling: two notices

Unnormalized paths and route rules (GHSA-9v7c-q64q-vv33 / CVE-2026-119200). Affects nuxt and @nuxt/nitro-server >=4.6.0 <4.6.3, fixed in 4.6.3. The page router resolves dot segments in a URL, but Nitro middleware and path-based route rules see the path before normalization. If your app relies on those rules for access checks, redirects or headers, and the path reaches the server unnormalized, a request may bypass them and server-rendered data from a protected page could be exposed. API handlers under server/api and server/routes are not reached, and checks in appMiddleware or definePageMeta that match the resolved route are unaffected. Nuxt 3 and Nuxt 4.0.0 to 4.5.x are not affected by this issue. A proxy that normalizes paths may remove the mismatch, but do not assume every CDN does. Upgrade, rebuild and redeploy, then have a developer review page authorization and path checks. Upstream notes that checking the request pathname alone is not a sufficient workaround, so prefer the upgrade over custom code. This is not a universal authentication bypass.

Server page islands and redirect rules (GHSA-2fxj-c3j7-rr69, no CVE known). Affects nuxt >=3.11.0 <4.6.3, fixed in 4.6.3 for Nuxt 4. An application is affected only if a .server.vue page has a matching redirect route rule and relies on that redirect to withhold rendered content. Independent server-side or route middleware checks are not implicated, and regular pages are outside this advisory. The fix applies page redirect rules during island rendering. A redirect is not authentication. Nuxt 3 will not receive a fix; upstream advises upgrading to Nuxt 4.

Development server only: three notices

None of these affect production builds. They matter only when a development server is reachable over TCP or HTTP by someone you do not trust.

  • Client error reports and file read (GHSA-x287-wcfc-q46c / CVE-2026-119198). @nuxt/vite-builder >=4.6.0 <4.6.3, fixed in 4.6.3. A reachable HMR socket allows reading any file the dev process can read, including secrets and keys. Direct TCP access to the dev server is required. The default localhost binding limits exposure, and a web page from another origin cannot retrieve files on its own. Nuxt 3 is not affected.
  • Inlined private runtime config (GHSA-648h-gw55-m2g7 / CVE-2026-119199). @nuxt/vite-builder >=3.0.0 <4.0.0 and >=4.0.0 <4.6.3, fixed in 4.6.3. With Nitro 2, the default in Nuxt 3 and 4, the dev bundle inlines private runtimeConfig values resolved at build time, so direct HTTP access to an exposed dev server allows reading them. Production and Nitro 3 are unaffected. Values left empty in nuxt.config and supplied through matching NUXT_* environment variables at startup are not inlined by this route, but that arrangement does not address the other notices. Nuxt 3 will not receive a fix.
  • Generated app secret (GHSA-3xf4-9g3c-4h4w / CVE-2026-119201). @nuxt/vite-builder >=4.6.0 <4.6.3, fixed in 4.6.3, only when no appSecret is explicitly configured. The generated .nuxt/app-secret file can be fetched by a directly reachable untrusted client, who could forge dev session cookies with the derived secret. Production never generates this file. An explicitly configured secret is not affected by this file issue, though it may still fall under the previous notice.

What to do

  1. Restrict any exposed development server immediately so it listens on localhost or sits behind authenticated access.
  2. Update to Nuxt 4.6.3 or a newer patched release. If you are on Nuxt 3, the 4.6.3 fix does not apply to you; plan the move to a supported Nuxt 4 release.
  3. Rebuild, redeploy and restart the relevant instances, then confirm the resolved versions in the deployed lockfile.
  4. Run functional and authorization checks in a staging environment you own, especially on pages protected by route rules or redirects. Take a backup first; our backup strategy guide explains how.
  5. If a vulnerable dev server could be reached by untrusted clients, apply the upstream precaution for each notice that matches your versions. For the file read notice, treat every file the dev process could read as exposed and rotate the credentials they held, including SSH keys and .env secrets. For the runtime config notice, rotate credentials defined through runtimeConfig in nuxt.config. For the generated secret notice, if the generated file could have been fetched, delete it so it is regenerated, or set a new NUXT_APP_SECRET, to invalidate dev sessions; a secret you configure yourself should be at least 32 random characters. These are precautions, not evidence that anything was taken.
  6. Preserve logs covering the exposure interval and review them. Our monitoring guide gives wider context on logging and alerting.

Limits of what is known

We found no report of exploitation of these five issues in the reviewed notices. That is not proof it has never occurred, and an absence of alerts on your side does not mean you were safe. Patching, verifying versions and reviewing your own access controls remain the reliable response. For wider context, see website security best practices.