Nuxt's May 2026 security release — four CVEs in the /__nuxt_island/* endpoint, including a route-middleware auth bypass (predates the July Server Island RCE batch)

View raw markdownEdit on GitHub ↗

TL;DR

Nuxt shipped a May 19, 2026 security release fixing four CVEs, all rooted in the same /__nuxt_island/* endpoint that also produced the already-tracked July 2026 Server Island RCE batch two months later. The headline bug, CVE-2026-47200, let an unauthenticated attacker bypass route-middleware-only authentication by requesting the island endpoint directly instead of the normal page route. Fixed in Nuxt 3.21.6 / 4.4.6. This is a distinct, earlier batch from the July one — same code area, same root cause pattern, different bugs.

What happened

Nuxt's component islands feature (experimental.componentIslands, default-on in Nuxt 4) lets a .server.vue page render server-side and be fetched independently via /__nuxt_island/page_<routeName>_<hash>. Because that endpoint renders the page component directly through the SSR renderer, it skipped the normal Vue Router instantiation that every other request path goes through — and route middleware (including definePageMeta({ middleware })) only runs as part of that router instantiation.

The practical effect: any Nuxt app that gates a .server.vue page behind route middleware as its sole authentication check (no additional server-side check) could have that check bypassed entirely by an unauthenticated attacker who requests /__nuxt_island/page_<routeName>_<anyhash> directly and receives the fully server-rendered HTML back.

Four CVEs shipped together in the same release, all fixed in Nuxt 3.21.6 / 4.4.6 (and the corresponding @nuxt/nitro-server, @nuxt/rspack-builder, @nuxt/webpack-builder versions):

  • CVE-2026-47200 (GHSA-hg3f-28rg-4jxj) — CVSS 4.0: 6.3 moderate. Route middleware not enforced when rendering .server.vue pages via the island endpoint, as described above. Affects nuxt 3.11.0–3.21.5 and 4.0.0-alpha.1–4.4.5; @nuxt/nitro-server 3.20.0–3.21.5 and 4.2.0–4.4.5.
  • CVE-2026-46342 (GHSA-g8wj-3cr3-6w7v) — CVSS 4.0: 2.3 low. The same /__nuxt_island/* endpoint accepts props via query parameters without server-side hash validation, letting an attacker "prime" a CDN cache for a given path with attacker-chosen props. In deployments combining path-only CDN caching with unsafe HTML sinks, this enables stored XSS that persists until the cache entry expires. Fixed by recomputing the expected hash server-side and rejecting mismatches with HTTP 400.
  • CVE-2026-45670 (GHSA-6m52-m754-pw2g) — CVSS 4.0: 5.9 moderate. An incomplete fix for an earlier source-exposure bug: running nuxt dev --host with the rspack/webpack builder exposed application source to any site on the same network, because the original fix relied on browser-sent security headers that untrustworthy origins simply don't send. The revised patch validates the request's Host header when those headers are absent. Dev-only; exploitation needs --host in use and Chrome < 142 (which added its own Local Network Access restrictions).
  • CVE-2026-45669 (GHSA-fx6j-w5w5-h468) — CVSS 4.0: 5.3 moderate. navigateTo(url, { external: true }) renders a server-side meta-refresh redirect but only escapes double quotes in the destination URL — <, >, &, and ' pass through unencoded. A common pattern (post-login redirect from a query parameter) becomes a reflected-XSS injection point: the injected script executes in the page before the redirect fires.

How this relates to the July 2026 batch already in this repo: the July 27, 2026 release (CVE-2026-71320 Server Island RCE, CVE-2026-71318, CVE-2026-71316, CVE-2026-71314/-71321, CVE-2026-71315) fixed a second, separate set of island/server-component bugs discovered after this May batch shipped — it built on top of 3.21.6/4.4.6, going up to 3.21.10/4.5.1. Both batches share the same underlying attack surface (the /__nuxt_island/* endpoint and server-rendered component islands), which is worth noting for anyone auditing whether their Nuxt app relies on component islands at all: this is now the second security-relevant batch in three months rooted in that one feature.

Am I affected?

# Check your installed Nuxt version
npm ls nuxt --depth=0
# or
cat node_modules/nuxt/package.json | grep '"version"'
  • Affected: nuxt 3.11.0–3.21.5 and 4.0.0-alpha.1–4.4.5. Fixed: ≥ 3.21.6 or ≥ 4.4.6 (and note you still need the July batch's 3.21.10/4.5.1 to be fully current).
  • You're most exposed to CVE-2026-47200 if experimental.componentIslands is enabled (Nuxt 4 default) and you have any .server.vue page under pages/ protected only by definePageMeta({ middleware: [...] }) with no additional server-side auth check inside the page/component itself.
  • You're exposed to CVE-2026-45670 only if you run nuxt dev --host (or equivalent) on a network with untrusted devices.

If you are affected

If CVE-2026-47200 applied to an authentication-gated page in production, treat it as a potential unauthorized-access incident: check server/CDN access logs for requests to /__nuxt_island/page_* paths that don't correspond to normal client-side navigation, especially from IPs with no prior session. See auditing-a-vibe-coded-repo.md for a general audit approach, and if-your-webapp-was-compromised.md if you find evidence of exploitation.

Prevention

  • Upgrade to Nuxt ≥ 3.21.10 / 4.5.1 (covers both this batch and the July one) rather than stopping at 3.21.6/4.4.6.
  • Don't rely on route middleware alone as your only auth boundary for a .server.vue page — add an explicit server-side check inside the component/page itself, since any endpoint that can render that component independently (now or in a future Nuxt feature) bypasses router-level middleware by construction.
  • See prevention/agent-sandboxing.md and prevention/ci-cd-hardening.md for related dev-server exposure hygiene (never run --host dev servers on untrusted networks).

Sources