════════════════════════════════════════════════════════════════════════════════
     CVE-2026 NUXT VULNERABILITIES - YANG BISA LEAD TO RCE
════════════════════════════════════════════════════════════════════════════════

Found 20 RCE-related advisories:

======================================================================
CVE: CVE-2026-71318
GHSA: GHSA-48hr-524c-v5w3
Severity: MEDIUM
Summary: Unauthorized Component Instantiation via Server Island Props in Nuxt

Description (excerpt):
## Impact

Nuxt server islands accept props via the `/__nuxt_island/` endpoint. When an application has a server island component that forwards props directly into Vue's dynamic component resolution (`<component :is>`, `resolveDynamicComponent`, or `h()`), an attacker can pass a plain string value (rather than a component definition) to instantiate any globally-registered Vue component or any native HTML element.

For example:
```json
{ "as": "SomeGlobalComponent" }
```

...resolves and renders `SomeGlobalComponent` if it is globally registered, even though the attacker should only be able to drive props for the island's declared component. Similarly, `{ "as": "iframe" }` renders an `<iframe>` element.

Unlike the primary RCE vector (GHSA-9473-5f9j-94wq), this does **not** require `vue.runtimeCompiler` to be enabled. A plain string prop is sufficient to trigger component resolution. The `template`/`render` key guard that addresses the RCE vector does not block plain string values.

Some component libraries expose a polymorphic `as` / `asChild` prop that forwards its value into `<component :is>`; `@nuxt/ui` (via `reka-ui`) is a widely used example. An application is affected if such a component receives the attacker-controlled value inside a server island. Note this does not require explicit prop forwarding: island props the island component does not declare fall through as attributes onto its single root element, so an island whose root is a `reka-ui` / `@nuxt/ui` component r

======================================================================
CVE: CVE-2026-71320
GHSA: GHSA-9473-5f9j-94wq
Severity: HIGH
Summary: Server-Side Remote Code Execution via Runtime Template Injection in Nuxt Server Island Props

Description (excerpt):
## Impact

Nuxt server islands accept props via the `/__nuxt_island/` endpoint. When `vue.runtimeCompiler: true` is enabled (off by default) and the application has a server island component that forwards props into Vue's dynamic component resolution (`<component :is>`, `resolveDynamicComponent`, or `h()`), an attacker can inject a `template` key into the island props to achieve server-side remote code execution in the Nitro process.

```json
{ "as": { "template": "<attacker-controlled>" } }
```

Vue's runtime template compiler compiles and executes the attacker-controlled `template` in the server process. The same primitive also works on the client side when the runtime compiler is active there, though the server-side path is the primary concern.

Some component libraries expose a polymorphic `as` / `asChild` prop that forwards its value into `<component :is>`; `@nuxt/ui` (via `reka-ui`) is a widely used example. An application is affected if such a component receives the attacker-controlled value, provided `vue.runtimeCompiler` is also enabled. Note this does not require the island author to explicitly forward a prop: island props that the island component does not declare fall through as attributes onto its single root element (standard Vue attribute inheritance), so an island whose root is a polymorphic component receives the attacker's `as` value implicitly. These libraries are not themselves vulnerable; they are noted only because they commonly provide the dynamic-compo

======================================================================
CVE: CVE-2026-71319
GHSA: GHSA-279x-mwfv-vcqv
Severity: CRITICAL
Summary: Unauthenticated Nuxt DevTools RPC allows arbitrary command execution on the developer's host

Description (excerpt):
### Impact

Nuxt DevTools (development mode only) exposes a bidirectional RPC channel over the Vite HMR WebSocket via the `nuxt:devtools:rpc` plugin. On affected versions the channel has no authentication: any client that can reach the Vite HMR endpoint (`ws://<host>:<port>/`, subprotocol `vite-hmr`) can call RPC methods, with no token, handshake, or origin check before the channel is established. The `updateOptions()`, `clearOptions()`, and `openInEditor()` methods do not enforce the `ensureDevAuthToken` check that the other mutating methods use.

`openInEditor()` reads the persisted `behavior.openInEditor` value and passes it to the `launch-editor` package, which spawns it as a child process. That value is settable through the equally unauthenticated `updateOptions()`. An attacker who can reach the HMR port can therefore chain `updateOptions('behavior', { openInEditor: '<command>' })` then `openInEditor('<any-existing-file>')` to execute an arbitrary program on the developer's machine.

The HMR port is reachable by a process on the same host, by any peer on the LAN when the dev server is bound with `nuxi dev --host`, or by a malicious website the developer visits while the dev server is running (a browser can open the HMR WebSocket cross-origin). Impact is limited to development environments; production builds do not run DevTools.

### Patches

Fixed in `@nuxt/devtools@3.3.1`. Because `nuxt` depends on `@nuxt/devtools` through a `^3.x` range, updating is a lockfil

======================================================================
CVE: None
GHSA: GHSA-7c4v-fwgw-9rf7
Severity: LOW
Summary: Nuxt dev server discloses project root and workspace UUID via the Chrome DevTools workspace endpoint

Description (excerpt):
### Impact

When a Nuxt dev server is bound to a network-reachable interface (for example `nuxt dev --host` for on-device testing), the default-enabled Chrome DevTools workspace endpoint `GET /.well-known/appspecific/com.chrome.devtools.json` returns the absolute project root (`workspace.root`, i.e. `rootDir`) and a persistent per-project workspace UUID.

`GHSA-rq7w-g337-39qq` added a gate (`isLocalDevRequest`) intended to restrict this endpoint to local requests, but that gate is header-based: it trusts request metadata rather than the connected peer address. A request with no `Sec-Fetch-Site`, `Origin`, and `Referer` headers (normal for a non-browser client such as `curl`) is treated as local, and the `Host` allow-list is compared against the attacker-supplied `Host` header. As a result, any unauthenticated host that can reach the dev server on the LAN can retrieve the project's absolute filesystem path and workspace UUID, for example with `curl -H 'Host: localhost' http://<dev-host-lan-ip>:3000/.well-known/appspecific/com.chrome.devtools.json`.

This is information disclosure only: there is no file read, file write, or code execution reachable from the endpoint. It requires the dev server to be reachable beyond loopback and `experimental.chromeDevtoolsProjectSettings` to be enabled (it defaults to `true`). Production builds are unaffected, because the endpoint is registered only as a development handler.

### Patches

Fixed in `nuxt@4.5.1` and `nuxt@3.21.10`. The endpoint 

======================================================================
CVE: CVE-2026-71315
GHSA: GHSA-hxvh-4h3w-prp9
Severity: HIGH
Summary: Nuxt route rules silently dropped for mixed-case paths, bypassing appMiddleware auth gates (incomplete fix for CVE-2026-53721)

Description (excerpt):
### Impact

Nuxt matches route rules case-insensitively by default (mirroring vue-router's default `sensitive: false` routing). The fix for GHSA-mm7m-92g8-7m47 / CVE-2026-53721 lowercased the *lookup* path before matching route rules, but the route-rule *keys* compiled into the matcher were left verbatim. As a result, any route rule whose key contains an uppercase character (for example `/Admin`, `/Dashboard/**`, or the rules Nuxt derives from PascalCase/camelCase page files such as `pages/Admin.vue`) never matches, because every lookup is folded to lowercase while the key stays mixed-case.

vue-router still serves the page case-insensitively, so the page renders with none of its Nuxt route-rule protections applied. The most serious consequence is an authorization bypass: an `appMiddleware` rule used as an auth gate (`routeRules: { '/Admin/dashboard': { appMiddleware: 'auth' } }`) is dropped, and `/Admin/dashboard`, `/admin/dashboard`, and `/ADMIN/dashboard` all render the protected page (and its SSR-fetched data) to an unauthenticated visitor instead of redirecting to login. The same gap drops Nuxt's other app-side route-rule behaviours for mixed-case keys, including the client redirect middleware, the app-side `ssr: false` decision, `prerender`, and payload handling.

### Patches

Fixed in `nuxt@4.5.1` (4.x) and `nuxt@3.21.10` (3.x). The route-rule matcher now case-folds the compiled keys the same way it folds the lookup path, so key and lookup normalisation are symmetric. 

======================================================================
CVE: CVE-2026-71321
GHSA: GHSA-9pgf-384g-p7mv
Severity: HIGH
Summary: Unauthenticated CPU exhaustion parsing and hashing the Nuxt island endpoint body before hash validation

Description (excerpt):
### Impact

The internal island renderer endpoint (`/__nuxt_island/...`) decodes and hashes attacker-controlled request input before it validates the URL-resident hash. An unauthenticated `POST /__nuxt_island/<name>_<anything>.json` with a large JSON body (for example ~4.6 MB / 150k keys) is fully read, `destr`-parsed, and run through `ohash` before the request is rejected with a 400. Because Nitro runs on a single event loop, this both wastes CPU on the doomed request and delays every concurrent request. A low request rate is enough to degrade or stall the server. No valid hash and no authentication are required.

### Patches

Fixed in `nuxt@4.5.1` and `nuxt@3.21.10`. The island handler now enforces a raw body-size cap (`413`) and a JSON nesting-depth cap (`400`) before parsing or hashing, so oversized or deeply nested input is rejected cheaply.

### Workarounds

Put a small request-body limit in front of `/__nuxt_island/` at your reverse proxy / edge (islands legitimately send only a compact props payload), or disable server components if unused.

### References

- Handler: `packages/nitro-server/src/runtime/handlers/island.ts`
- Guard: `packages/nitro-server/src/runtime/utils/island-props.ts`

======================================================================
CVE: CVE-2026-71314
GHSA: GHSA-hxcr-hm88-mpq6
Severity: HIGH
Summary: Unauthenticated out-of-memory crash via unbounded v-for expansion in Nuxt island rendering

Description (excerpt):
### Impact

An unauthenticated attacker can crash a Nuxt server that renders any island / server component containing a `v-for` over a prop (for example `v-for="n in count"` or a `<slot v-for>`). Because the island URL hash is a non-secret digest of the request, the attacker can compute a valid hash for arbitrary props and send the iterated prop as a large integer. The server then expands the `v-for` to that many nodes during SSR, allocating memory proportional to the attacker's number. Reporter figures: `count=8000000` produced a 142.9 MB response; `count=40000000` (and `items=4000000` on a slot list) produced an out-of-memory crash of the worker from a single ~130-byte request. Both the plain `v-for` path (Vue's `ssrRenderList`) and the slot path (`vforToArray`) are affected.

### Patches

Fixed in `nuxt@4.5.1` and `nuxt@3.21.10`. Island/server-component `v-for` sources are now clamped to a maximum iteration count (`MAX_VFOR_LENGTH = 100000`) at the render boundary, covering the plain path, the `<slot v-for>` element, and the `vforToArray` slot-props helper. Combined with the body-size cap (GHSA-9pgf-384g-p7mv), a single island render can no longer allocate without bound regardless of which `v-for` path is used or whether the prop arrives as an integer or an array.

### Workarounds

Avoid `v-for` directly over an unclamped prop in server components, or clamp the count in the component (`v-for="n in Math.min(count, 1000)"`). A body-size limit in front of `/__nuxt_island/` on

======================================================================
CVE: CVE-2026-53721
GHSA: GHSA-mm7m-92g8-7m47
Severity: HIGH
Summary: Route-rule middleware bypass via case-sensitivity mismatch between vue-router and the routeRules matcher

Description (excerpt):
## Impact

Nuxt looks up `routeRules` for the current navigation by calling
`getRouteRules({ path: to.path })` from the page-router plugin and the
no-pages router plugin. The compiled `routeRules` matcher (built on
`rou3`) performs case-sensitive matching, while vue-router is configured
with its default `sensitive: false` and matches paths case-insensitively.

The two routers therefore disagree on which rules apply to a given
request path: vue-router still matches the page record for
`/Admin/dashboard`, but the `routeRules` lookup for the same path
returns no match. Any `appMiddleware` declared via `routeRules` is never
added to the middleware set and never runs, on both SSR and client
navigations. The same path skips other path-keyed route rules in the
same way (`ssr`, `redirect`, `appLayout`, and the prerender / payload
hints used client-side).

For applications using `routeRules` with `appMiddleware` as an
authorization gate (a documented pattern), an attacker can flip the case
of any static segment in a protected URL (for example `/Admin/dashboard`
instead of `/admin/dashboard`) to render the protected page with the
middleware skipped. The server returns the fully server-rendered page
including any `useFetch` / `useAsyncData` results captured during SSR.

This is an instance of CWE-178 (Improper Handling of Case Sensitivity)
leading to CWE-863 (Incorrect Authorization) for apps that treat
`appMiddleware` as an authorization boundary.

## Mitigating factors

- Only affects

======================================================================
CVE: None
GHSA: GHSA-m3q2-p4fw-w38m
Severity: LOW
Summary: Cross-site scripting via <NoScript> slot content in Nuxt's head components

Description (excerpt):
### Impact

Nuxt's globally registered `<NoScript>` component (from `@unhead/vue` head components, re-exported by Nuxt) wrote its default-slot content to the `innerHTML` of the `<noscript>` head tag, bypassing the HTML escaping that `{{ }}` interpolation normally applies in Vue templates.

Applications that placed untrusted, attacker-controllable data inside a `<NoScript>` slot, for example:

```vue
<NoScript>{{ route.query.banner }}</NoScript>
```

would emit that value unescaped inside `<noscript>` in the server-rendered HTML. With scripting enabled, the HTML parser treats `<noscript>` content in `<head>` under the "in head noscript" insertion mode: any tag other than `link`, `meta`, `noframes`, or `style` implicitly closes `<noscript>` and is re-processed in the head. A payload such as `<script>...</script>` therefore escapes the element and executes in the document context.

Sibling head components (`<Style>`, `<Title>`) were not affected because they already routed slot text through the safe `textContent` path.

### Affected versions

All currently supported versions of `nuxt` that ship the `<NoScript>` global component.

### Patches

Fixed in `nuxt@4.4.7` (commit [`4b054e9d`](https://github.com/nuxt/nuxt/commit/4b054e9d95f8daf366cb144b52782047c511a66e)) and backported to `nuxt@3.21.7` (commit [`7fea9fd6`](https://github.com/nuxt/nuxt/commit/7fea9fd687f1dacbfb63db5fae5839896b017a0e)). The fix escapes `<NoScript>` slot content with `escapeHtml` from `@vue/shared` and writ

======================================================================
CVE: CVE-2026-49993
GHSA: GHSA-x6qj-4h56-5rj5
Severity: MEDIUM
Summary: @nuxt/webpack-builder and @nuxt/rspack-builder dev server same-origin check bypassed when Sec-Fetch-Site, Origin, and Referer are all absent (incomplete fix for GHSA-6m52-m754-pw2g)

Description (excerpt):
### Summary
This is an incomplete fix for [GHSA-6m52-m754-pw2g](https://github.com/nuxt/nuxt/security/advisories/GHSA-6m52-m754-pw2g). Source code may still be stolen during dev when using the webpack / rspack builder if the dev server is bound to a non-loopback address (e.g. `nuxt dev --host`) and the developer opens a malicious site on the same network.

### Details
The fix for [GHSA-6m52-m754-pw2g](https://github.com/nuxt/nuxt/security/advisories/GHSA-6m52-m754-pw2g) added an `Origin` / `Referer` fallback to the dev-middleware same-origin check, with a `return true` branch when neither header is present so that non-browser clients (curl, the HMR client, address-bar navigation) keep working.

That fallback is bypassed when a cross-origin attacker request reaches the dev server with all three signal headers absent:

- `Sec-Fetch-Site` is [not sent by browsers to non-potentially-trustworthy destinations](https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header) (HTTP on a non-loopback address).
- `Origin` is not sent on non-CORS subresource fetches (a bare `<script>` with no `crossorigin`).
- `Referer` can be suppressed by the attacker page with `<meta name="referrer" content="no-referrer">` or `referrerpolicy="no-referrer"` on the `<script>` element.

A classic `<script src="http://VICTIM_LAN_IP:3000/_nuxt/app.js" referrerpolicy="no-referrer">` from a non-trustworthy attacker origin produces exactly that header set, the request is allowed, and the attacker page 

======================================================================
CVE: CVE-2026-53722
GHSA: GHSA-934w-87qh-qr26
Severity: MEDIUM
Summary: Reflected XSS in `<NuxtLink>` via unsanitised `javascript:` or `data:` URL

Description (excerpt):
### Summary

`<NuxtLink>` did not validate the URL scheme of values bound to its `to` or `href` props before rendering them into the `href` attribute of the underlying `<a>` element. When an application binds attacker-controlled input (a query parameter, a CMS field, a user-supplied profile URL) to `<NuxtLink :to>` or `:href`, the attacker can supply a `javascript:` or `vbscript:` URL that is reflected verbatim into the rendered markup. Clicking the link executes the supplied script in the origin of the Nuxt application, resulting in reflected DOM-based cross-site scripting. A `data:text/html,...` payload reflected through the same sink does not execute in the application's origin but enables a same-tab phishing surface anchored to a legitimate application link.

The same value was exposed to consumers of the component's `custom` slot via the `href` and `route.href` props, so applications that re-bind those values to their own anchors were affected identically.

Unlike the previously reported `navigateTo` issue (CVE-2024-34343), the sink here is the rendered anchor itself; the existing `isScriptProtocol` checks in `navigateTo` and `reloadNuxtApp` are not on the code path. The `onClick` handler intentionally returns early for external links so the browser's native protocol-based navigation runs.

### Affected component

- File: `packages/nuxt/src/app/components/nuxt-link.ts`
- Sink: `h('a', { href: href.value, ... })` in the default render, plus the `href` / `route.href` props

======================================================================
CVE: None
GHSA: GHSA-rq7w-g337-39qq
Severity: LOW
Summary: Dev server discloses project absolute path and persistent workspace UUID via `/.well-known/appspecific/com.chrome.devtools.json`

Description (excerpt):
### Summary

When running `nuxt dev`, Nuxt registers an unauthenticated route at `/.well-known/appspecific/com.chrome.devtools.json` that returns the absolute filesystem path of the project root and a per-project UUID persisted to `node_modules/.cache/nuxt/chrome-workspace.json`. The route is enabled by default via `experimental.chromeDevtoolsProjectSettings: true`.

The endpoint exists to let Chrome DevTools' Workspace integration map sources to the developer's local checkout. The handler is registered directly on `nitro.options.devHandlers` and does not pass through the CORS / origin wrapper that the rest of the dev pipeline uses, so it has no host / origin / `Sec-Fetch-Site` check of its own.

### Impact

Dev-server only. Production builds do not register the route.

Two values are disclosed:

- `workspace.root`: the absolute filesystem path of the project (commonly reveals the OS username and the on-disk project name).
- `workspace.uuid`: a v4 UUID persisted to `node_modules/.cache/nuxt/chrome-workspace.json`, stable across dev-server restarts and re-clones.

### Threat model

The response carries no `Access-Control-Allow-Origin` header. A cross-origin `fetch()` from an arbitrary malicious page is therefore blocked by the browser's same-origin policy and cannot read the body. The two realistic recovery paths are:

1. **LAN-adjacent attacker** when the developer runs `nuxt dev --host` (or otherwise binds to a non-loopback interface). A plain `curl http://<dev-lan-ip>:3000/

======================================================================
CVE: CVE-2026-45669
GHSA: GHSA-fx6j-w5w5-h468
Severity: MEDIUM
Summary: Reflected XSS in `navigateTo` external redirect

Description (excerpt):
### Summary
`navigateTo()` with `external: true` generates a server-side HTML redirect body containing a `<meta http-equiv="refresh">` tag. The destination URL is only sanitized by replacing `"` with `%22`, leaving `<`, `>`, `&`, and `'` unencoded. An attacker who can influence the URL passed to `navigateTo(url, { external: true })` can break out of the `content="…"` attribute and inject arbitrary HTML/JavaScript that executes under the application's origin.

This is a different root cause from CVE-2024-34343 (GHSA-vf6r-87q4-2vjf), which addressed `javascript:` protocol bypass. The issue here is triggered by any valid URL containing `>`.

### Impact
Applications that pass user-controlled input to `navigateTo(url, { external: true })` — typically via a `?next=` / `?redirect=` query parameter used for post-login or "return to" flows — are vulnerable to reflected cross-site scripting. The injected script runs in the context of the application's origin during the server-rendered redirect response, before the meta-refresh fires.

### Details
In `packages/nuxt/src/app/composables/router.ts`, the SSR redirect path builds an HTML response body with only `"` percent-encoded in the destination URL:

```ts
const encodedLoc = location.replace(/"/g, '%22')
nuxtApp.ssrContext!['~renderResponse'] = {
status: sanitizeStatusCode(options?.redirectCode || 302, 302),
body: `<!DOCTYPE html><html><head><meta http-equiv="refresh" content="0; url=${encodedLoc}"></head></html>`,
heade

======================================================================
CVE: CVE-2026-45670
GHSA: GHSA-6m52-m754-pw2g
Severity: MEDIUM
Summary: Dev server exposes built source over LAN to malicious sites (incomplete fix for GHSA-4gf7-ff8x-hq99)

Description (excerpt):
### Summary
This is an incomplete fix for [GHSA-4gf7-ff8x-hq99](https://github.com/nuxt/nuxt/security/advisories/GHSA-4gf7-ff8x-hq99). Source code may be stolen during dev when using the webpack / rspack builder if the dev server is bound to a non-loopback address (e.g. `nuxt dev --host`) and the developer opens a malicious site on the same network.

### Details
The fix for [GHSA-4gf7-ff8x-hq99](https://github.com/nuxt/nuxt/security/advisories/GHSA-4gf7-ff8x-hq99) relied on Sec-Fetch-Mode and Sec-Fetch-Site headers. Because [these headers are sent by the browsers only for potentially trustworthy origins](https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header:~:text=Site%20header%20for%20a%20request%20r%3A-,Assert%3A%20r%E2%80%99s%20url%20is%20a%20potentially%20trustworthy%20URL.,-Let%20header%20be%20a%20Structured%20Field%20whose), the check is able to bypass for non-potentially trustworthy origins.

Since the attack requires the website to be accessible via a non-potentially trustworthy origin, only apps that are using `--host` is affected.

### PoC
1. Create a nuxt project with webpack / rspack builder.
1. Run `npm run dev`
1. Open `http://localhost:3000`
1. Run the script below in a web site that has a different origin.
1. You can see the source code output in the document and the devtools console.

```js
const script = document.createElement('script')
script.src = 'http://192.168.0.31:3000/_nuxt/app.js' // NOTE: replace with the IP address 

======================================================================
CVE: CVE-2026-46342
GHSA: GHSA-g8wj-3cr3-6w7v
Severity: LOW
Summary: `__nuxt_island` response not bound to request props

Description (excerpt):
### Summary

The `/__nuxt_island/*` endpoint accepts attacker-controlled `props` query/body parameters and renders any island component without verifying that the URL-resident hash (`<Name>_<hashId>.json`) was actually issued for those inputs by `<NuxtIsland>`. The hash is computed and embedded client-side but never validated server-side, so the same path can return materially different responses depending on the query.

Island components are documented as rendering independently of route context - page middleware does not apply to them, and they are intentionally cacheable as a function of their props. This advisory does **not** treat that contract as a vulnerability. It treats the absence of a binding between the URL the cache keys on and the response served at that URL as one.

### Impact

In applications where a CDN or reverse-proxy in front of the app caches `/__nuxt_island/*` keyed by path only (ignoring query) - a documented misconfiguration class, see GHSA-jvhm-gjrh-3h93 - an attacker can prime the cache for a path with their own choice of props, and subsequent users requesting the same path receive the attacker's rendered HTML rather than the response intended for them. The cache entry persists until normal expiry.

Where the affected island has any prop flowing into an unsafe HTML sink in application code (`v-html`, `innerHTML`, a third-party renderer treating a prop as HTML), this becomes stored XSS in the embedding page's origin until the cache entry exp

======================================================================
CVE: CVE-2026-47200
GHSA: GHSA-hg3f-28rg-4jxj
Severity: MEDIUM
Summary: Route middleware not enforced when rendering `.server.vue` pages via `/__nuxt_island/page_*`

Description (excerpt):
### Summary

When `experimental.componentIslands` is enabled (default in Nuxt 4), any `.server.vue` file under `pages/` is automatically registered as a server island under the key `page_<routeName>` and exposed via the `/__nuxt_island/:name` endpoint. Until this fix, requests through that endpoint rendered the page component directly via the SSR renderer without instantiating Vue Router, which meant route middleware declared on the page (including `definePageMeta({ middleware })`) did not run.

For Nuxt applications that gate a `.server.vue` *page* behind route middleware as their sole auth check, an unauthenticated attacker could bypass that check by requesting `/__nuxt_island/page_<routeName>_<anyhash>` directly and receiving the server-rendered HTML.

### Affected configurations

All three conditions must hold for an application to be vulnerable:

1. `experimental.componentIslands` is enabled (the default in Nuxt 4; opt-in in Nuxt 3).
2. The application defines one or more `.server.vue` files under `pages/`, registering them as routed pages.
3. Authentication / authorization for at least one such page is enforced solely via route middleware (`middleware/*.ts` referenced from `definePageMeta`), without a server-side check inside the page or its data layer.

Applications that enforce auth inside the island's own data layer (server-only API routes, `useRequestEvent` + manual session checks, etc.) were not affected. The general "route middleware does not run for

======================================================================
CVE: CVE-2025-24361
GHSA: GHSA-4gf7-ff8x-hq99
Severity: MEDIUM
Summary: Opening a malicious website while running a Nuxt dev server could allow read-only access to code

Description (excerpt):
### Summary
Source code may be stolen during dev when using webpack / rspack builder and you open a malicious web site.

### Details
Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject `<script src="http://localhost:3000/_nuxt/app.js">` in their site and run the script.
By using `Function::toString` against the values in `window.webpackChunknuxt_app`, the attacker can get the source code.

### PoC
1. Create a nuxt project with webpack / rspack builder.
1. Run `npm run dev`
1. Open `http://localhost:3000`
1. Run the script below in a web site that has a different origin.
1. You can see the source code output in the document and the devtools console.

```js
const script = document.createElement('script')
script.src = 'http://localhost:3000/_nuxt/app.js'
script.addEventListener('load', () => {
  for (const page in window.webpackChunknuxt_app) {
    const moduleList = window.webpackChunknuxt_app[page][1]
    console.log(moduleList)

    for (const key in moduleList) {
      const p = document.createElement('p')
      const title = document.createElement('strong')
      title.textContent = key
      const code = document.createElement('code')
      code.textContent = moduleList[key].toString()
      p.append(title, ':', document.createElement('br'), code)
      document.body.appendChild(p)
    }
  }
})
document.head.appendChild(script)
```

![image](https://github.com/user-attachmen

======================================================================
CVE: CVE-2025-24360
GHSA: GHSA-2452-6xj8-jh47
Severity: MEDIUM
Summary: Opening a malicious website while running a Nuxt dev server could allow read-only access to code

Description (excerpt):
### Summary
Nuxt allows any websites to send any requests to the development server and read the response due to default CORS settings.

### Details
While Vite patched the default CORS settings to fix https://github.com/vitejs/vite/security/advisories/GHSA-vg6x-rcgg-rjx6, nuxt uses its own CORS handler by default (https://github.com/nuxt/nuxt/pull/23995).

https://github.com/nuxt/nuxt/blob/7d345c71462d90187fd09c96c7692f306c90def5/packages/vite/src/client.ts#L257-L263

That CORS handler sets `Access-Control-Allow-Origin: *`.

> [!IMPORTANT]  
> If on an affected version, it may be possible to opt-out of the default Nuxt CORS handler by configuring `vite.server.cors`.

### PoC
1. Start a dev server in any nuxt project using Vite by `nuxt dev`.
2. Send a fetch request to `http://localhost:3000/_nuxt/app.vue` (`fetch('http://localhost:3000/_nuxt/app.vue')`) from a different origin page.

### Impact
Users with the default server.cors option using Vite builder may get the source code stolen by malicious websites

### Additional Information
`/__nuxt_vite_node__/manifest` / `/__nuxt_vite_node__/module` also seems to have `Access-Control-Allow-Origin: *`, so it maybe also possible to exploit that handler.
https://github.com/nuxt/nuxt/blob/7d345c71462d90187fd09c96c7692f306c90def5/packages/vite/src/vite-node.ts#L39
Although I didn't find a valid module id.
Note that this handler is probably also vulnerable to DNS rebinding attacks as I didn't find any host header

======================================================================
CVE: CVE-2024-34344
GHSA: GHSA-v784-fjjh-f8r4
Severity: HIGH
Summary: Remote code execution via the browser when running e2e tests locally

Description (excerpt):
### Summary
Due to the insufficient validation of the `path` parameter in the NuxtTestComponentWrapper, an attacker can execute arbitrary JavaScript on the server side, which allows them to execute arbitrary commands.

### Impact
Users who open a malicious web page in the browser while running the test locally are affected by this vulnerability, which results in the remote code execution from the malicious web page.
Since web pages can send requests to arbitrary addresses, a malicious web page can repeatedly try to exploit this vulnerability, which then triggers the exploit when the test server starts.

======================================================================
CVE: CVE-2024-23657
GHSA: GHSA-rcvg-rgf7-pppv
Severity: HIGH
Summary: Path Traversal: '../filedir' in Nuxt Devtools

Description (excerpt):
### Summary
Nuxt Devtools is missing authentication on the `getTextAssetContent` RPC function which is vulnerable to path traversal.  Combined with a lack of Origin checks on the WebSocket handler,  an attacker is able to interact with a locally running devtools instance and exfiltrate data abusing this vulnerability. 

In certain configurations an attacker could leak the devtools authentication token and then abuse other RPC functions to achieve RCE. 

### Details
The `getTextAssetContent` function does not check for path traversals [(source)](https://github.com/nuxt/devtools/blob/c4f2b68281203fc3f61ffc97d9c6623fbfde46bb/packages/devtools/src/server-rpc/assets.ts#L88C48-L88C48), this could allow an attacker to read arbitrary files over the RPC WebSocket. 

The WebSocket server does not check the origin of the request [(source)](https://github.com/nuxt/devtools/blob/c4f2b68281203fc3f61ffc97d9c6623fbfde46bb/packages/devtools/src/server-rpc/index.ts#L109) leading to [CSWSH](https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking). This may be intentional to allow certain configurations to work correctly.

Nuxt Devtools authentication tokens are placed within the home directory of the current user  [(source)](https://github.com/nuxt/devtools/blob/c4f2b68281203fc3f61ffc97d9c6623fbfde46bb/packages/devtools/src/dev-auth.ts#L14).

In the scenario that:
 + The user has a Nuxt3 Project running
 + Devtools is enabled and running
 + The project is p