Posts tagged "Nuxt-js"

The Nuxt team has disclosed several security vulnerabilities fixed in Nuxt 4.5.1 and 3.21.10, ranging from a high-severity server-side remote code execution (under specific conditions) to lower-severity and development-only issues. Here’s what Netlify customers need to know.

Vulnerabilities

• GHSA-9473-5f9j-94wq (High): remote code execution via server island props
• GHSA-48hr-524c-v5w3 (Medium): unauthorized component instantiation via server island props
• GHSA-hxvh-4h3w-prp9 (High): route rule authorization bypass when a route rule key contains an uppercase character
• GHSA-hxcr-hm88-mpq6 and GHSA-9pgf-384g-p7mv (High): server component denial of service
• GHSA-wm8w-6qjm-cv43 (High): cross-user disclosure of cached payloads (Nuxt 4.x only, 4.4.0 and later)
• GHSA-7c4v-fwgw-9rf7 (Low): dev server path disclosure
• GHSA-279x-mwfv-vcqv (Critical, development only): remote code execution in Nuxt DevTools, fixed in @nuxt/devtools@3.3.1

Impact on Netlify

Remote code execution (GHSA-9473-5f9j-94wq)

This issue only applies under uncommon conditions: it requires Vue’s runtime compiler (vue.runtimeCompiler: true, which is off by default) and a server island that forwards untrusted input into a component. Few applications meet both conditions, so real-world exposure is limited. We’ve proactively reached out to the very small number of Netlify customers whose projects could potentially be affected.

Route rule authorization bypass (GHSA-hxvh-4h3w-prp9)

This is a framework-level issue that affects Nuxt apps regardless of hosting provider. It is not specific to Netlify. You’re affected if you use routeRules with appMiddleware as an authorization gate and any rule key contains an uppercase character, such as a rule derived from a page like pages/Admin.vue or written explicitly as routeRules: { '/Admin': ... }. Because routing is case-insensitive by default, the page was served while its route rule (and the middleware guarding it) was silently skipped. This is a regression in the earlier fix for CVE-2026-53721, so upgrading only to 4.4.7 or 3.21.7 does not protect you. Upgrade to Nuxt 4.5.1 or 3.21.10, then audit any uppercase route rule keys used for access control.

Denial of service (GHSA-hxcr-hm88-mpq6, GHSA-9pgf-384g-p7mv)

These are server-side denial-of-service (DoS) vulnerabilities. On Netlify, these have minimal impact: our autoscaling serverless architecture means that a malicious request resulting in a crashed or hung function does not affect other requests. However, active exploitation could increase your function costs.

Cross-user payload disclosure (GHSA-wm8w-6qjm-cv43)

If you use the cache, swr, or isr route rules on authenticated pages that render user-specific data, a cached payload could be served to the wrong user. After upgrading, purge any upstream CDN cache (e.g. Akamai or Cloudflare) that may already be holding a leaked payload. Upgrading alone won’t evict it.

Development-only issues (GHSA-279x-mwfv-vcqv, GHSA-7c4v-fwgw-9rf7)

The Nuxt DevTools remote code execution and the dev server path disclosure only affect local development, not deployed Netlify sites. Still, refresh your lockfile so it picks up @nuxt/devtools@3.3.1.

What should I do?

We strongly recommend upgrading as soon as possible to a patched release:

• nuxt 4.5.1 or later (for Nuxt 4)
• nuxt 3.21.10 or later (for Nuxt 3)

Running npx nuxt upgrade --dedupe also refreshes your lockfile so it pulls in @nuxt/devtools@3.3.1, which fixes the critical development-only issue above.

Note that any publicly available deploy previews and branch deploys may remain vulnerable until they are automatically deleted. Consider deleting these deploys manually.

Resources

• Nuxt security post
• Nuxt security advisories

The Nuxt team has disclosed four security vulnerabilities. Here’s what Netlify customers need to know.

Vulnerabilities

• CVE-2026-47200: Route middleware bypass via island page endpoints (nuxt 3.11.0–3.21.5, 4.0.0-alpha.1–4.4.5)
• CVE-2026-46342: Island response not validated against request props (nuxt 3.1.0–3.21.5, 4.0.0-alpha.1–4.4.5)
• CVE-2026-45670: Dev server exposes built source over LAN (nuxt 3.15.4–3.21.5, 4.0.0-alpha.1–4.4.5)
• CVE-2026-45669: Reflected XSS via navigateTo with external: true (nuxt 3.4.3–3.21.5, 4.0.0-alpha.1–4.4.5)

Impact on Netlify

CVE-2026-47200 (route middleware bypass)

When component islands are enabled — the default in Nuxt 4, and available via an opt-in flag in Nuxt 3 — .server.vue page files are accessible via /__nuxt_island/page_* endpoints that render pages without invoking Vue Router, bypassing route middleware entirely. An unauthenticated attacker can request these endpoints directly to access pages that rely solely on middleware for access control.

Regardless of hosting provider, all affected Nuxt apps using .server.vue pages with route-middleware-only authentication are vulnerable.

CVE-2026-46342 (island cache poisoning)

The /__nuxt_island/* endpoint accepts props via query parameters without server-side hash validation, allowing the same path to return different content depending on query parameters. If an upstream cache keys on path only, an attacker can inject crafted props into cached responses — enabling XSS if the application renders those props through unsafe HTML sinks.

On Netlify, cached function responses vary by query string. This vulnerability requires overriding Netlify’s default Netlify-Vary behavior and is not exploitable in standard Netlify deployments.

CVE-2026-45670 (dev server source exposure)

Running nuxt dev --host binds the development server to a non-loopback address; with the rspack or webpack builder (not the default Vite builder), malicious sites on the same network can access the application’s source code. This only affects local development environments.

Netlify production deployments are not affected. Developers should avoid using --host with rspack or webpack builders, or upgrade to patch the issue.

CVE-2026-45669 (reflected XSS via navigateTo)

When navigateTo() is called with external: true, Nuxt generates a server-side HTML meta-refresh redirect. The destination URL is insufficiently sanitized — HTML-significant characters are not encoded, so an attacker who controls the URL parameter can inject arbitrary scripts that execute before the redirect occurs.

Regardless of hosting provider, all apps passing untrusted user input to navigateTo() with external: true are vulnerable.

What should I do?

We strongly recommend upgrading as soon as possible to patched releases:

• nuxt 3.21.6 or later (for Nuxt 3.x), or 4.4.6 or later (for Nuxt 4.x)
• @nuxt/rspack-builder and @nuxt/webpack-builder 3.21.6 or later, or 4.4.6 or later (if applicable)

Note that any publicly available deploy previews and branch deploys may remain vulnerable until they are automatically deleted. Consider deleting these deploys manually.

Resources

• Nuxt security advisories

Today we’re announcing two major updates for Nuxt developers on Netlify:

Day-One Nuxt 4 Support

Nuxt 4 launched today, and Netlify is ready. Deploy your Nuxt 4 apps with zero configuration changes—everything just works. Everything is fully compatible from day one.

Learn more about leveraging platform primitives with Nuxt.

Full Platform Emulation in Your Dev Server with @netlify/nuxt

We’re also launching @netlify/nuxt today, a new Nuxt module that brings the entire Netlify platform into your local development environment. Functions, Edge Functions, Blobs, Image CDN, env vars, headers, and redirects all work directly in nuxt dev—no separate CLI required.

Add the module to your Nuxt 3 or Nuxt 4 app with one command:

npx nuxi module add @netlify/nuxt

This simplifies local development and enables AI coding assistants to build full-stack apps with immediate feedback.

Read the complete guide.