CVE-2026-71320

## 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-component sink. ## Common configurations that satisfy the preconditions The flaw is in Nuxt core. The library below is not itself vulnerable; it is noted because it commonly provides the dynamic-component sink an application might inadvertently expose. - **`@nuxt/ui`** (via its underlying **`reka-ui`** primitives) exposes a polymorphic `as` / `asChild` prop that is forwarded into Vue's dynamic-component resolution. Installing `@nuxt/ui` does not by itself register any component as a server island. Exploitation requires the application to define an island component (a `.server.vue` file) whose rendered output puts the attacker-controlled value on such a component's `as` / `asChild` prop; with `vue.runtimeCompiler: true`, the attacker-controlled `template` is then compiled and executed. Because undeclared island props fall through as attributes to the single root, this can happen without any explicit binding: an island whose root is a `reka-ui` / `@nuxt/ui` component is enough. An example vulnerable island (the `as` value falls through to `UButton`, no explicit forwarding needed): ```vue <!-- components/MyWidget.server.vue --> <template> <UButton>Save</UButton> </template> ``` The island URL hash (`/__nuxt_island/<Name>_<hash>.json`) is a deterministic (unsalted) content hash, not an authentication token. It provides integrity relative to the URL but is not a security boundary: an attacker who knows the component name and desired props can compute a valid hash. ## Mitigating factors - `vue.runtimeCompiler` is **off by default** in Nuxt. The vast majority of Nuxt applications are not affected. - Exploitation requires a **second precondition**: the application must have a server island component that puts an attacker-controlled value onto a dynamic-component path (`<component :is>`, `resolveDynamicComponent`, `h()`, or a polymorphic `as` / `asChild` prop). This can occur explicitly or via attribute fallthrough when the island's root is such a component. - SSG / static deployments are largely unreachable via this vector (no server process to exploit). - Island component names are constrained to the build-time component registry; an attacker cannot resolve arbitrary components. ## Affected versions Nuxt `>=3.4.0 <3.21.10` and `>=4.0.0 <4.5.1`, and only when `vue.runtimeCompiler: true` and component islands are active. Earlier versions did not allow the Vue compiler to be enabled in the server bundle (the compiler dependencies have been mock-aliased on the server since v3.0.0-rc.1), so the runtime-compilation path is not reachable. Nuxt 2 is not affected (no server islands). ## Patches When `vue.runtimeCompiler` is enabled, island requests whose decoded props contain a `template` key at any depth are rejected with an HTTP 400 and a diagnostic suggesting the author rename the prop or disable the runtime compiler. The guard is gated on the runtime compiler being enabled, so the default configuration (compiler off) is unaffected and legitimate props that merely contain a `template` field (for example CMS content) continue to render. A `render` key is not rejected: island props arrive as JSON, so a `render` value can only be an inert string, which Vue ignores. Fixed in `[email protected]` and backported to `[email protected]`. ## Workarounds Upgrade to `[email protected]` or `[email protected]`. If you cannot immediately upgrade, you can mitigate by: 1. Ensure `vue.runtimeCompiler` is set to `false` (the default). 2. Do not forward island props into `<component :is>`, `resolveDynamicComponent`, or `h()` without sanitization. 3. As a defense-in-depth measure, deploy a WAF rule on `/__nuxt_island/` that URL-decodes and JSON-parses the `props` value and blocks any object property named `template` or `render` in the decoded island props, inspecting both query and body for all methods. Note: this only covers direct and browser-originated island requests; initial-SSR internal island renders do not transit the edge and a WAF alone does not close the vector.