chore(deps): update dependency nuxt to v4.5.1 [security] #26

renovate-bot · 2026-08-07T05:13:51Z

renovate-bot commented

2026-08-07 05:13:51 +00:00

This PR contains the following updates:

Package	Change	Age	Confidence
nuxt (source)	`4.5.0` → `4.5.1`

Nuxt: Unauthorized Component Instantiation via Server Island Props

CVE-2026-71318 / GHSA-48hr-524c-v5w3

More information

Details

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:

{ "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 receives the attacker's as value implicitly. Unlike the RCE vector, no vue.runtimeCompiler is required, which makes this vector reachable in more configurations. These libraries are not themselves vulnerable; they are noted only because they commonly provide the dynamic-component sink. Installing @nuxt/ui does not by itself register any component as a server island: the application must define the island (a .server.vue file).

Mitigating factors

Exploitation requires 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), either explicitly or via attribute fallthrough when the island's root is such a component.
Reachable components are limited to what is actually in the island app's global registry. In a default pages-enabled app that is RouterView and RouterLink (both registered globally by the pages router plugin, which runs even in component islands), plus any components/global/ component and any component a module registers globally. RouterLink in particular renders an attacker-influenced <a> (and, because an island that declares no props forwards all props, to and other RouterLink props ride the same fallthrough). Vue built-ins (Transition, KeepAlive, Teleport, Suspense) and Nuxt auto-imports (ClientOnly, NuxtLink, NuxtPage, etc.) are NOT in the island app's global registry and cannot be resolved this way; an unresolved name instead renders as a native HTML element (the element-injection half of this issue).
Declaring the props an island accepts, or setting inheritAttrs: false on it, prevents an undeclared as from falling through to a polymorphic root and neutralizes this vector.
Arbitrary JavaScript execution is not possible through this vector (no template/render compilation).
Island component names are constrained to the build-time component registry; an attacker cannot resolve arbitrary components.

Affected versions

Nuxt >=3.1.0 <3.21.10 and >=4.0.0 <4.5.1, with component islands active. The island prop-forwarding behavior has existed since server islands were introduced in v3.1.0, and this vector does not depend on vue.runtimeCompiler. Nuxt 2 is not affected.

Note the patch (below) closes the implicit attribute-fallthrough path, which is the majority case. An island that explicitly forwards an untrusted prop into dynamic component resolution (or forwards it under a prop name other than as) remains the application's responsibility in every version; see Workarounds.

Patches

Fixed in nuxt@4.5.1 and nuxt@3.21.10. Patched releases reject a top-level as island prop (HTTP 400 at the /__nuxt_island/ endpoint). This closes the implicit path: island props an island does not declare fall through as attributes onto its single root, so a top-level as would otherwise reach a polymorphic root component's as prop (the reka-ui / @nuxt/ui convention) and drive dynamic component resolution without the author binding it. Rejecting the top-level as prop blocks that fallthrough while leaving nested data and other prop names untouched.

The framework deliberately does not attempt to block every case: it cannot safely tell a string used as data from one used as a component selector, and it has no island-local hook into Vue's h() or resolveDynamicComponent(). An island that explicitly forwards an untrusted value into <component :is> / h() / resolveDynamicComponent(), or that forwards it under a different polymorphic prop name, is therefore not covered by the patch and must follow the guidance below. The Nuxt documentation now warns against this.

Workarounds

Upgrade to nuxt@4.5.1 or nuxt@3.21.10. That upgrade also removes the related object-prop RCE (GHSA-9473-5f9j-94wq). In addition, in any version:

Do not forward island props into <component :is>, resolveDynamicComponent, or h(). Map an untrusted discriminator through a closed allowlist of imported component definitions instead of passing the raw prop value.
Declare the props an island accepts, or set inheritAttrs: false on it, so request input cannot fall through to a polymorphic root component.
Avoid registering sensitive components globally that could leak information if instantiated by an attacker.

Severity

CVSS Score: 4.8 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Nuxt dev server discloses project root and workspace UUID via the Chrome DevTools workspace endpoint

GHSA-7c4v-fwgw-9rf7

More information

Details

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 now additionally requires the connected TCP peer to be a loopback address, verified from the socket rather than from request headers, so a non-loopback LAN client is rejected regardless of the Host, Origin, Referer, or Sec-Fetch-* headers it sends. The shared header-based check is left unchanged, so the CSRF / same-origin behaviour that other dev handlers rely on is preserved. After this fix, Chrome DevTools workspace auto-mapping only works when the browser reaches the dev server over loopback (localhost / 127.0.0.1 / ::1), which matches the feature's intent (the browser and dev server sharing a filesystem).

Workarounds

Do not bind the dev server to a non-loopback interface on an untrusted network, or restrict access to the dev port with a firewall.
Disable the feature by setting experimental.chromeDevtoolsProjectSettings: false in nuxt.config.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Nuxt: Server-Side Remote Code Execution via Runtime Template Injection in Nuxt Server Island Props

CVE-2026-71320 / GHSA-9473-5f9j-94wq

More information

Details

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.

{ "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):
```

<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 nuxt@4.5.1 and backported to nuxt@3.21.10.

Workarounds

Upgrade to nuxt@4.5.1 or nuxt@3.21.10. If you cannot immediately upgrade, you can mitigate by:

Ensure vue.runtimeCompiler is set to false (the default).
Do not forward island props into <component :is>, resolveDynamicComponent, or h() without sanitization.
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.

Severity

CVSS Score: 8.1 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Nuxt: Unauthenticated CPU exhaustion parsing and hashing the Nuxt island endpoint body before hash validation

CVE-2026-71321 / GHSA-9pgf-384g-p7mv

More information

Details

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.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Nuxt: Unauthenticated out-of-memory crash via unbounded v-for expansion in island rendering

CVE-2026-71314 / GHSA-hxcr-hm88-mpq6

More information

Details

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/ only mitigates array-shaped inputs, not the integer-amplification case.

References

Bound helper: packages/nuxt/src/app/components/vfor.ts
Transform: packages/nuxt/src/components/plugins/islands-transform.ts
Slot helper: packages/nuxt/src/app/components/utils.ts (vforToArray)

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Nuxt route rules silently dropped for mixed-case paths, bypassing appMiddleware auth gates (incomplete fix for CVE-2026-53721)

CVE-2026-71315 / GHSA-hxvh-4h3w-prp9

More information

Details

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. Both sides are gated on router.options.sensitive: with sensitive: true (case-sensitive routing) configured casing is preserved on both sides.

Scope note: server-emitted per-route headers, server redirect, and proxy are matched by Nitro's own case-sensitive route-rule matcher, not by Nuxt's app-level matcher. They are unchanged by this advisory. The fix covers the app-level protections Nuxt owns (appMiddleware, appLayout, the client redirect middleware, the app ssr decision, prerender, and payload).

Workarounds

If you cannot upgrade immediately, any one of:

Key all routeRules (and name your page files) in lowercase, so the keys already match the folded lookup path.
Set router: { options: { sensitive: true } } so routing and route-rule matching are both case-sensitive and exact (requests must then use the exact casing).
Enforce the sensitive protections server-side independently of route rules (for example a server middleware that checks auth), which does not rely on case-insensitive route-rule matching.

Severity

CVSS Score: 8.2 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Nuxt runtime payload cache discloses another user's SSR data across users and to unauthenticated clients

CVE-2026-71316 / GHSA-wm8w-6qjm-cv43

More information

Details

Impact

When a page is covered by routeRules cache / swr / isr, Nuxt enables runtime payload extraction and serves /<page>/_payload.json. On affected versions the renderer stored the SSR payload in the shared cache:nuxt:payload storage under a path-only key (no cookie, authorization, or cache.varies dimension) and, on a later payload request, returned the cached entry before route middleware / page guards ran again.

As a result, once any authenticated user warms a protected, cached page, a subsequent GET /<page>/_payload.json from an unauthenticated client or a different authenticated user receives the first user's payload: the full SSR data for that route, including anything loaded via useFetch / useAsyncData (for example /api/me: profile, tenant, billing, token-like values). The HTML response stays correctly varied and protected; only the extracted payload leaks. Both cross-user (A warms, B receives A) and unauthenticated disclosure are exploitable. cache.varies does not mitigate it, because the payload cache ignores varies.

Introduced when runtime payload extraction landed for cached routes (#34410); the regression is specific to the 4.x line, where the runtime cache:nuxt:payload storage was added and the import.meta.prerender gate on the payload-cache read/writes was dropped. The 3.x line shipped the same feature with the gate intact and is not affected.

Patches

Fixed in nuxt@4.5.1. Runtime payload-cache reads and writes are again confined to prerendering (import.meta.prerender); at runtime, /<page>/_payload.json follows the normal render path so route middleware, routeRules.appMiddleware, and page guards run for the current request. main / v5 and the 3.x line already had this property, so 3.x is not affected.

Workarounds

Set experimental.payloadExtraction: false (reporter-validated): the standalone /_payload.json endpoint returns 404 and the page still serves a 200 with an inline payload.
Do not apply cache / swr / isr to authenticated pages that render user-specific SSR data.
As defense-in-depth, require authentication for /**/_payload.json at a proxy / CDN.
After upgrading, purge any CDN / platform cache that may already hold protected payloads.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

❗ Important

Release Notes retrieval for this PR were skipped because no github.com credentials were available.
If you are self-hosted, please see this instruction.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate.

This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [nuxt](https://nuxt.com) ([source](https://github.com/nuxt/nuxt/tree/HEAD/packages/nuxt)) | [`4.5.0` → `4.5.1`](https://renovatebot.com/diffs/npm/nuxt/4.5.0/4.5.1) | ![age](https://developer.mend.io/api/mc/badges/age/npm/nuxt/4.5.1?slim=true) | ![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/nuxt/4.5.0/4.5.1?slim=true) | --- ### Nuxt: Unauthorized Component Instantiation via Server Island Props [CVE-2026-71318](https://nvd.nist.gov/vuln/detail/CVE-2026-71318) / [GHSA-48hr-524c-v5w3](https://github.com/advisories/GHSA-48hr-524c-v5w3) <details> <summary>More information</summary> #### Details ##### 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 receives the attacker's `as` value implicitly. Unlike the RCE vector, no `vue.runtimeCompiler` is required, which makes this vector reachable in more configurations. These libraries are not themselves vulnerable; they are noted only because they commonly provide the dynamic-component sink. Installing `@nuxt/ui` does not by itself register any component as a server island: the application must define the island (a `.server.vue` file). ##### Mitigating factors - Exploitation requires 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), either explicitly or via attribute fallthrough when the island's root is such a component. - Reachable components are limited to what is actually in the island app's global registry. In a default pages-enabled app that is `RouterView` and `RouterLink` (both registered globally by the pages router plugin, which runs even in component islands), plus any `components/global/` component and any component a module registers globally. `RouterLink` in particular renders an attacker-influenced `<a>` (and, because an island that declares no props forwards all props, `to` and other `RouterLink` props ride the same fallthrough). Vue built-ins (`Transition`, `KeepAlive`, `Teleport`, `Suspense`) and Nuxt auto-imports (`ClientOnly`, `NuxtLink`, `NuxtPage`, etc.) are NOT in the island app's global registry and cannot be resolved this way; an unresolved name instead renders as a native HTML element (the element-injection half of this issue). - Declaring the props an island accepts, or setting `inheritAttrs: false` on it, prevents an undeclared `as` from falling through to a polymorphic root and neutralizes this vector. - Arbitrary JavaScript execution is not possible through this vector (no `template`/`render` compilation). - Island component names are constrained to the build-time component registry; an attacker cannot resolve arbitrary components. ##### Affected versions Nuxt `>=3.1.0 <3.21.10` and `>=4.0.0 <4.5.1`, with component islands active. The island prop-forwarding behavior has existed since server islands were introduced in v3.1.0, and this vector does not depend on `vue.runtimeCompiler`. Nuxt 2 is not affected. Note the patch (below) closes the implicit attribute-fallthrough path, which is the majority case. An island that *explicitly* forwards an untrusted prop into dynamic component resolution (or forwards it under a prop name other than `as`) remains the application's responsibility in every version; see Workarounds. ##### Patches Fixed in `nuxt@4.5.1` and `nuxt@3.21.10`. Patched releases reject a top-level `as` island prop (HTTP 400 at the `/__nuxt_island/` endpoint). This closes the implicit path: island props an island does not declare fall through as attributes onto its single root, so a top-level `as` would otherwise reach a polymorphic root component's `as` prop (the `reka-ui` / `@nuxt/ui` convention) and drive dynamic component resolution without the author binding it. Rejecting the top-level `as` prop blocks that fallthrough while leaving nested data and other prop names untouched. The framework deliberately does not attempt to block every case: it cannot safely tell a string used as data from one used as a component selector, and it has no island-local hook into Vue's `h()` or `resolveDynamicComponent()`. An island that explicitly forwards an untrusted value into `<component :is>` / `h()` / `resolveDynamicComponent()`, or that forwards it under a different polymorphic prop name, is therefore not covered by the patch and must follow the guidance below. The Nuxt documentation now warns against this. ##### Workarounds Upgrade to `nuxt@4.5.1` or `nuxt@3.21.10`. That upgrade also removes the related object-prop RCE (GHSA-9473-5f9j-94wq). In addition, in any version: 1. Do not forward island props into `<component :is>`, `resolveDynamicComponent`, or `h()`. Map an untrusted discriminator through a closed allowlist of imported component definitions instead of passing the raw prop value. 2. Declare the props an island accepts, or set `inheritAttrs: false` on it, so request input cannot fall through to a polymorphic root component. 3. Avoid registering sensitive components globally that could leak information if instantiated by an attacker. #### Severity - CVSS Score: 4.8 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N` #### References - [https://github.com/nuxt/nuxt/security/advisories/GHSA-48hr-524c-v5w3](https://github.com/nuxt/nuxt/security/advisories/GHSA-48hr-524c-v5w3) - [https://github.com/nuxt/nuxt](https://github.com/nuxt/nuxt) - [https://github.com/nuxt/nuxt/releases/tag/v3.21.10](https://github.com/nuxt/nuxt/releases/tag/v3.21.10) - [https://github.com/nuxt/nuxt/releases/tag/v4.5.1](https://github.com/nuxt/nuxt/releases/tag/v4.5.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-48hr-524c-v5w3) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### Nuxt dev server discloses project root and workspace UUID via the Chrome DevTools workspace endpoint [GHSA-7c4v-fwgw-9rf7](https://github.com/advisories/GHSA-7c4v-fwgw-9rf7) <details> <summary>More information</summary> #### Details ##### 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 now additionally requires the connected TCP peer to be a loopback address, verified from the socket rather than from request headers, so a non-loopback LAN client is rejected regardless of the `Host`, `Origin`, `Referer`, or `Sec-Fetch-*` headers it sends. The shared header-based check is left unchanged, so the CSRF / same-origin behaviour that other dev handlers rely on is preserved. After this fix, Chrome DevTools workspace auto-mapping only works when the browser reaches the dev server over loopback (`localhost` / `127.0.0.1` / `::1`), which matches the feature's intent (the browser and dev server sharing a filesystem). ##### Workarounds - Do not bind the dev server to a non-loopback interface on an untrusted network, or restrict access to the dev port with a firewall. - Disable the feature by setting `experimental.chromeDevtoolsProjectSettings: false` in `nuxt.config`. #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N` #### References - [https://github.com/nuxt/nuxt/security/advisories/GHSA-7c4v-fwgw-9rf7](https://github.com/nuxt/nuxt/security/advisories/GHSA-7c4v-fwgw-9rf7) - [https://github.com/nuxt/nuxt/commit/00f71bb6517abff67257c8ea1fcdc777b938b68d](https://github.com/nuxt/nuxt/commit/00f71bb6517abff67257c8ea1fcdc777b938b68d) - [https://github.com/nuxt/nuxt/commit/e30c611ea03240f341fe784ab1711aa6424da2fa](https://github.com/nuxt/nuxt/commit/e30c611ea03240f341fe784ab1711aa6424da2fa) - [https://github.com/nuxt/nuxt](https://github.com/nuxt/nuxt) - [https://github.com/nuxt/nuxt/releases/tag/v3.21.10](https://github.com/nuxt/nuxt/releases/tag/v3.21.10) - [https://github.com/nuxt/nuxt/releases/tag/v4.5.1](https://github.com/nuxt/nuxt/releases/tag/v4.5.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-7c4v-fwgw-9rf7) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### Nuxt: Server-Side Remote Code Execution via Runtime Template Injection in Nuxt Server Island Props [CVE-2026-71320](https://nvd.nist.gov/vuln/detail/CVE-2026-71320) / [GHSA-9473-5f9j-94wq](https://github.com/advisories/GHSA-9473-5f9j-94wq) <details> <summary>More information</summary> #### Details ##### 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  <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 `nuxt@4.5.1` and backported to `nuxt@3.21.10`. ##### Workarounds Upgrade to `nuxt@4.5.1` or `nuxt@3.21.10`. 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. #### Severity - CVSS Score: 8.1 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/nuxt/nuxt/security/advisories/GHSA-9473-5f9j-94wq](https://github.com/nuxt/nuxt/security/advisories/GHSA-9473-5f9j-94wq) - [https://github.com/nuxt/nuxt/commit/5b60017f7f1d5e9384cadf1d6c580b99d583c418](https://github.com/nuxt/nuxt/commit/5b60017f7f1d5e9384cadf1d6c580b99d583c418) - [https://github.com/nuxt/nuxt/commit/ee6c846338f4eb75801815dda86df1f494725859](https://github.com/nuxt/nuxt/commit/ee6c846338f4eb75801815dda86df1f494725859) - [https://github.com/nuxt/nuxt](https://github.com/nuxt/nuxt) - [https://github.com/nuxt/nuxt/releases/tag/v3.21.10](https://github.com/nuxt/nuxt/releases/tag/v3.21.10) - [https://github.com/nuxt/nuxt/releases/tag/v4.5.1](https://github.com/nuxt/nuxt/releases/tag/v4.5.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-9473-5f9j-94wq) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### Nuxt: Unauthenticated CPU exhaustion parsing and hashing the Nuxt island endpoint body before hash validation [CVE-2026-71321](https://nvd.nist.gov/vuln/detail/CVE-2026-71321) / [GHSA-9pgf-384g-p7mv](https://github.com/advisories/GHSA-9pgf-384g-p7mv) <details> <summary>More information</summary> #### Details ##### 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. #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` #### References - [https://github.com/nuxt/nuxt/security/advisories/GHSA-9pgf-384g-p7mv](https://github.com/nuxt/nuxt/security/advisories/GHSA-9pgf-384g-p7mv) - [https://github.com/nuxt/nuxt/commit/4e35ae9babd94be53246e31200232d48438bb34e](https://github.com/nuxt/nuxt/commit/4e35ae9babd94be53246e31200232d48438bb34e) - [https://github.com/nuxt/nuxt/commit/668cdfdfda41849ed11c1ee5e2067a11fc103b22](https://github.com/nuxt/nuxt/commit/668cdfdfda41849ed11c1ee5e2067a11fc103b22) - [https://github.com/nuxt/nuxt](https://github.com/nuxt/nuxt) - [https://github.com/nuxt/nuxt/releases/tag/v3.21.10](https://github.com/nuxt/nuxt/releases/tag/v3.21.10) - [https://github.com/nuxt/nuxt/releases/tag/v4.5.1](https://github.com/nuxt/nuxt/releases/tag/v4.5.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-9pgf-384g-p7mv) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### Nuxt: Unauthenticated out-of-memory crash via unbounded v-for expansion in island rendering [CVE-2026-71314](https://nvd.nist.gov/vuln/detail/CVE-2026-71314) / [GHSA-hxcr-hm88-mpq6](https://github.com/advisories/GHSA-hxcr-hm88-mpq6) <details> <summary>More information</summary> #### Details ##### 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/` only mitigates array-shaped inputs, not the integer-amplification case. ##### References - Bound helper: `packages/nuxt/src/app/components/vfor.ts` - Transform: `packages/nuxt/src/components/plugins/islands-transform.ts` - Slot helper: `packages/nuxt/src/app/components/utils.ts` (`vforToArray`) #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` #### References - [https://github.com/nuxt/nuxt/security/advisories/GHSA-hxcr-hm88-mpq6](https://github.com/nuxt/nuxt/security/advisories/GHSA-hxcr-hm88-mpq6) - [https://github.com/nuxt/nuxt/commit/4e35ae9babd94be53246e31200232d48438bb34e](https://github.com/nuxt/nuxt/commit/4e35ae9babd94be53246e31200232d48438bb34e) - [https://github.com/nuxt/nuxt/commit/668cdfdfda41849ed11c1ee5e2067a11fc103b22](https://github.com/nuxt/nuxt/commit/668cdfdfda41849ed11c1ee5e2067a11fc103b22) - [https://github.com/nuxt/nuxt](https://github.com/nuxt/nuxt) - [https://github.com/nuxt/nuxt/releases/tag/v3.21.10](https://github.com/nuxt/nuxt/releases/tag/v3.21.10) - [https://github.com/nuxt/nuxt/releases/tag/v4.5.1](https://github.com/nuxt/nuxt/releases/tag/v4.5.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-hxcr-hm88-mpq6) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### Nuxt route rules silently dropped for mixed-case paths, bypassing appMiddleware auth gates (incomplete fix for CVE-2026-53721) [CVE-2026-71315](https://nvd.nist.gov/vuln/detail/CVE-2026-71315) / [GHSA-hxvh-4h3w-prp9](https://github.com/advisories/GHSA-hxvh-4h3w-prp9) <details> <summary>More information</summary> #### Details ##### 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. Both sides are gated on `router.options.sensitive`: with `sensitive: true` (case-sensitive routing) configured casing is preserved on both sides. Scope note: server-emitted per-route `headers`, server `redirect`, and `proxy` are matched by Nitro's own case-sensitive route-rule matcher, not by Nuxt's app-level matcher. They are unchanged by this advisory. The fix covers the app-level protections Nuxt owns (`appMiddleware`, `appLayout`, the client redirect middleware, the app `ssr` decision, `prerender`, and payload). ##### Workarounds If you cannot upgrade immediately, any one of: - Key all `routeRules` (and name your page files) in lowercase, so the keys already match the folded lookup path. - Set `router: { options: { sensitive: true } }` so routing and route-rule matching are both case-sensitive and exact (requests must then use the exact casing). - Enforce the sensitive protections server-side independently of route rules (for example a server middleware that checks auth), which does not rely on case-insensitive route-rule matching. #### Severity - CVSS Score: 8.2 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N` #### References - [https://github.com/nuxt/nuxt/security/advisories/GHSA-hxvh-4h3w-prp9](https://github.com/nuxt/nuxt/security/advisories/GHSA-hxvh-4h3w-prp9) - [https://github.com/nuxt/nuxt/commit/619963309e082190bac4a26b05f2dd155b039b81](https://github.com/nuxt/nuxt/commit/619963309e082190bac4a26b05f2dd155b039b81) - [https://github.com/nuxt/nuxt/commit/ad624a75ad2d215f43633f6b40be346a7194d34d](https://github.com/nuxt/nuxt/commit/ad624a75ad2d215f43633f6b40be346a7194d34d) - [https://github.com/nuxt/nuxt](https://github.com/nuxt/nuxt) - [https://github.com/nuxt/nuxt/releases/tag/v3.21.10](https://github.com/nuxt/nuxt/releases/tag/v3.21.10) - [https://github.com/nuxt/nuxt/releases/tag/v4.5.1](https://github.com/nuxt/nuxt/releases/tag/v4.5.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-hxvh-4h3w-prp9) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### Nuxt runtime payload cache discloses another user's SSR data across users and to unauthenticated clients [CVE-2026-71316](https://nvd.nist.gov/vuln/detail/CVE-2026-71316) / [GHSA-wm8w-6qjm-cv43](https://github.com/advisories/GHSA-wm8w-6qjm-cv43) <details> <summary>More information</summary> #### Details ##### Impact When a page is covered by `routeRules` `cache` / `swr` / `isr`, Nuxt enables runtime payload extraction and serves `/<page>/_payload.json`. On affected versions the renderer stored the SSR payload in the shared `cache:nuxt:payload` storage under a path-only key (no cookie, `authorization`, or `cache.varies` dimension) and, on a later payload request, returned the cached entry before route middleware / page guards ran again. As a result, once any authenticated user warms a protected, cached page, a subsequent `GET /<page>/_payload.json` from an unauthenticated client or a different authenticated user receives the first user's payload: the full SSR data for that route, including anything loaded via `useFetch` / `useAsyncData` (for example `/api/me`: profile, tenant, billing, token-like values). The HTML response stays correctly varied and protected; only the extracted payload leaks. Both cross-user (A warms, B receives A) and unauthenticated disclosure are exploitable. `cache.varies` does not mitigate it, because the payload cache ignores `varies`. Introduced when runtime payload extraction landed for cached routes (#34410); the regression is specific to the 4.x line, where the runtime `cache:nuxt:payload` storage was added and the `import.meta.prerender` gate on the payload-cache read/writes was dropped. The 3.x line shipped the same feature with the gate intact and is not affected. ##### Patches Fixed in `nuxt@4.5.1`. Runtime payload-cache reads and writes are again confined to prerendering (`import.meta.prerender`); at runtime, `/<page>/_payload.json` follows the normal render path so route middleware, `routeRules.appMiddleware`, and page guards run for the current request. `main` / v5 and the `3.x` line already had this property, so 3.x is not affected. ##### Workarounds - Set `experimental.payloadExtraction: false` (reporter-validated): the standalone `/_payload.json` endpoint returns 404 and the page still serves a 200 with an inline payload. - Do not apply `cache` / `swr` / `isr` to authenticated pages that render user-specific SSR data. - As defense-in-depth, require authentication for `/**/_payload.json` at a proxy / CDN. - After upgrading, purge any CDN / platform cache that may already hold protected payloads. #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/nuxt/nuxt/security/advisories/GHSA-wm8w-6qjm-cv43](https://github.com/nuxt/nuxt/security/advisories/GHSA-wm8w-6qjm-cv43) - [https://github.com/nuxt/nuxt/commit/ac9b41a36b62296a117862254ee7d2b21a2a5203](https://github.com/nuxt/nuxt/commit/ac9b41a36b62296a117862254ee7d2b21a2a5203) - [https://github.com/nuxt/nuxt](https://github.com/nuxt/nuxt) - [https://github.com/nuxt/nuxt/releases/tag/v4.5.1](https://github.com/nuxt/nuxt/releases/tag/v4.5.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-wm8w-6qjm-cv43) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> > :exclamation: **Important** > > Release Notes retrieval for this PR were skipped because no github.com credentials were available. > If you are self-hosted, please see [this instruction](https://github.com/renovatebot/renovate/blob/master/docs/usage/examples/self-hosting.md#githubcom-token-for-release-notes). --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).

renovate-bot added 1 commit

2026-08-07 05:13:52 +00:00

chore(deps): update dependency nuxt to v4.5.1 [security]

baseline-security / baseline (push) Failing after 1m0s

Details

baseline-security / baseline (pull_request) Failing after 1m0s

Details

scan / trivy-fs (push) Failing after 48s

Details

scan / trivy-fs (pull_request) Failing after 46s

Details

ai-review / review (pull_request) Successful in 3m24s

Details

e90b4d6060

A-Guevara was assigned by renovate-bot

2026-08-07 05:13:58 +00:00

ai-review-bot reviewed

2026-08-07 05:29:34 +00:00

ai-review-bot left a comment

AI review · advisory

Verdict: 6 things worth fixing (1 high · 2 medium · 3 low).

Findings that didn't map to a diff line:

node_modules/@nuxt/kit/package.json:243 · MEDIUM — Unnecessary addition of new dependency "verkit"
The newly added "verkit" dependency increases the supply‑chain attack surface without a clear usage in the codebase.

Fix: Remove "verkit" from @nuxt/kit dependencies unless it is explicitly required; run a dependency audit to confirm no code imports it.

node_modules/@nuxt/kit/package.json:197 · LOW — Removal of semver from @nuxt/kit dependencies
"semver" was removed from @nuxt/kit's dependencies, which may break internal code that expects it at runtime.

Fix: Re‑add "semver": "^7.8.5" to @nuxt/kit dependencies if any code imports it, or verify that the package no longer uses semver.

node_modules/@nuxt/kit/package.json:215 · LOW — Potential version drift for @nuxt/devtools and related packages
The @nuxt/devtools version was bumped from 3.2.4 to 3.4.1 without updating its peer dependency constraints, which could lead to mismatched expectations in downstream plugins.

Fix: Verify compatibility of the new @nuxt/devtools version with all consuming plugins and update peer dependency ranges if necessary.

node_modules/@nuxt/vite-builder/package.json:355 · LOW — Addition of "generic-names" may be unnecessary
"generic-names" is added as a dependency of @nuxt/vite-builder but does not appear to be used, adding bloat and potential vulnerabilities.

Fix: Confirm whether @nuxt/vite-builder actually requires "generic-names"; if not, remove it from the dependencies.

package-lock.json:2742 · MEDIUM — Dependency version mismatch
The version of @nuxt/kit in @nuxt/devtools-kit does not match the version in @nuxt/kit.

Fix: Ensure the version of @nuxt/kit in @nuxt/devtools-kit matches the version in @nuxt/kit.

_{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 13 distinct, 6 confirmed, 0 refuted · web: not used · context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)}

Panel debate — how this review was reached

Grounding — context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)

Round 1 — independent reviews

GPT-OSS 120B (5 findings, confidence 0.92): The dependency updates mostly look safe, but the undici engine requirement, new verkit addition, and a few unnecessary dependencies warrant attention.
Gemma 4 31B (0 findings, confidence 1.0): The diff is a standard dependency update for Nuxt and its ecosystem to v4.5.1, including the expected lockfile churn (version bumps and removal of libc constraints), and contains no correctness or sec
Devstral 2 123B (8 findings, confidence 0.9): The package-lock.json file has several inconsistencies and missing dependencies that need to be addressed.
Laguna S 2.1 (0 findings, confidence 0.95): This PR is a routine automated dependency bump (nuxt 4.5.0 → 4.5.1) reflected in package-lock.json; no source code was changed, the lockfile updates are consistent with the declared dependency range (

Round 2 — cross-examination

GPT-OSS 120B#1 Undici version bump introduces Node engine incompatibility · confirmed: Gemma 4 31B, Devstral 2 123B · refuted: —
Devstral 2 123B#7 Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#2 Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#4 Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#6 Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#3 Missing dependency · confirmed: GPT-OSS 120B · refuted: Gemma 4 31B
Devstral 2 123B#5 Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#8 Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
GPT-OSS 120B#2 Unnecessary addition of new dependency "verkit" · confirmed: Gemma 4 31B · refuted: —
Devstral 2 123B#1 Version mismatch in package-lock.json · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
GPT-OSS 120B#3 Removal of semver from @nuxt/kit dependencies · confirmed: Gemma 4 31B · refuted: —
GPT-OSS 120B#5 Potential version drift for @nuxt/devtools and related packages · confirmed: Gemma 4 31B · refuted: —

Synthesis — Devstral 2 123B wrote the final review from 6 confirmed findings (+7 unconfirmed).

_{Transcript rv-20260807052654-fb14a0 — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.}

_{Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript rv-20260807052654-fb14a0.}

### AI review · advisory **Verdict: 6 things worth fixing** (1 high · 2 medium · 3 low). Findings that didn't map to a diff line: **`node_modules/@nuxt/kit/package.json:243`** · MEDIUM — Unnecessary addition of new dependency "verkit" The newly added "verkit" dependency increases the supply‑chain attack surface without a clear usage in the codebase. > **Fix:** Remove "verkit" from @nuxt/kit dependencies unless it is explicitly required; run a dependency audit to confirm no code imports it. **`node_modules/@nuxt/kit/package.json:197`** · LOW — Removal of semver from @nuxt/kit dependencies "semver" was removed from @nuxt/kit's dependencies, which may break internal code that expects it at runtime. > **Fix:** Re‑add "semver": "^7.8.5" to @nuxt/kit dependencies if any code imports it, or verify that the package no longer uses semver. **`node_modules/@nuxt/kit/package.json:215`** · LOW — Potential version drift for @nuxt/devtools and related packages The @nuxt/devtools version was bumped from 3.2.4 to 3.4.1 without updating its peer dependency constraints, which could lead to mismatched expectations in downstream plugins. > **Fix:** Verify compatibility of the new @nuxt/devtools version with all consuming plugins and update peer dependency ranges if necessary. **`node_modules/@nuxt/vite-builder/package.json:355`** · LOW — Addition of "generic-names" may be unnecessary "generic-names" is added as a dependency of @nuxt/vite-builder but does not appear to be used, adding bloat and potential vulnerabilities. > **Fix:** Confirm whether @nuxt/vite-builder actually requires "generic-names"; if not, remove it from the dependencies. **`package-lock.json:2742`** · MEDIUM — Dependency version mismatch The version of @nuxt/kit in @nuxt/devtools-kit does not match the version in @nuxt/kit. > **Fix:** Ensure the version of @nuxt/kit in @nuxt/devtools-kit matches the version in @nuxt/kit. ⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 13 distinct, 6 confirmed, 0 refuted · web: not used · context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) <details> <summary>Panel debate — how this review was reached</summary> **Grounding** — context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) **Round 1 — independent reviews** - **GPT-OSS 120B** (5 findings, confidence 0.92): The dependency updates mostly look safe, but the undici engine requirement, new verkit addition, and a few unnecessary dependencies warrant attention. - **Gemma 4 31B** (0 findings, confidence 1.0): The diff is a standard dependency update for Nuxt and its ecosystem to v4.5.1, including the expected lockfile churn (version bumps and removal of libc constraints), and contains no correctness or sec - **Devstral 2 123B** (8 findings, confidence 0.9): The package-lock.json file has several inconsistencies and missing dependencies that need to be addressed. - **Laguna S 2.1** (0 findings, confidence 0.95): This PR is a routine automated dependency bump (nuxt 4.5.0 → 4.5.1) reflected in package-lock.json; no source code was changed, the lockfile updates are consistent with the declared dependency range ( **Round 2 — cross-examination** - `GPT-OSS 120B#1` Undici version bump introduces Node engine incompatibility · confirmed: Gemma 4 31B, Devstral 2 123B · refuted: — - `Devstral 2 123B#7` Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#2` Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#4` Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#6` Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#3` Missing dependency · confirmed: GPT-OSS 120B · refuted: Gemma 4 31B - `Devstral 2 123B#5` Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#8` Missing dependency · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `GPT-OSS 120B#2` Unnecessary addition of new dependency "verkit" · confirmed: Gemma 4 31B · refuted: — - `Devstral 2 123B#1` Version mismatch in package-lock.json · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `GPT-OSS 120B#3` Removal of semver from @nuxt/kit dependencies · confirmed: Gemma 4 31B · refuted: — - `GPT-OSS 120B#5` Potential version drift for @nuxt/devtools and related packages · confirmed: Gemma 4 31B · refuted: — **Synthesis** — Devstral 2 123B wrote the final review from 6 confirmed findings (+7 unconfirmed). Transcript `rv-20260807052654-fb14a0` — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway. </details> Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript `rv-20260807052654-fb14a0`.

package-lock.json

					
				@ -1,12 +1,12 @@

				{

LOW — Version mismatch in package-lock.json

The version in the root of package-lock.json does not match the version in the packages section.

Fix: Ensure the version in the root of package-lock.json matches the version in the packages section.

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**LOW** — Version mismatch in package-lock.json The version in the root of package-lock.json does not match the version in the packages section. > **Fix:** Ensure the version in the root of package-lock.json matches the version in the packages section. panel tally 1/4 · reply here or use the finding board to agree/disagree

package-lock.json

					
				@ -1865,4 +1862,1 @@

				      "libc": [

				        "glibc"

				      ],

				      "license": "LGPL-3.0-or-later",

package-lock.json:1862 · HIGH — Undici version bump introduces Node engine incompatibility
The new undici version (8.10.0) requires Node >=22.19.0, which likely exceeds the runtime Node version used in CI and production, causing install or runtime failures.

Fix: Pin undici to a version compatible with the project's Node version (e.g., 8.8.0) or upgrade the CI and production Node runtime to >=22.19.0.

_{panel tally 3/4 · reply here or use the finding board to agree/disagree}

**`package-lock.json:1862`** · HIGH — Undici version bump introduces Node engine incompatibility The new undici version (8.10.0) requires Node >=22.19.0, which likely exceeds the runtime Node version used in CI and production, causing install or runtime failures. > **Fix:** Pin undici to a version compatible with the project's Node version (e.g., 8.8.0) or upgrade the CI and production Node runtime to >=22.19.0. panel tally 3/4 · reply here or use the finding board to agree/disagree

package-lock.json

					
				@ -3083,7 +3035,7 @@

				        "ufo": "^1.6.4",

				        "unctx": "^3.0.0",

package-lock.json:3036 · MEDIUM — Missing dependency
The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it.

Fix: Add 'semver' as a dependency in @nuxt/kit's dependencies.

_{panel tally 2/4 · reply here or use the finding board to agree/disagree}

**`package-lock.json:3036`** · MEDIUM — Missing dependency The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it. > **Fix:** Add 'semver' as a dependency in @nuxt/kit's dependencies. panel tally 2/4 · reply here or use the finding board to agree/disagree

package-lock.json:3036 · MEDIUM — Missing dependency
The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it.

Fix: Add 'semver' as a dependency in @nuxt/kit's dependencies.

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**`package-lock.json:3036`** · MEDIUM — Missing dependency The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it. > **Fix:** Add 'semver' as a dependency in @nuxt/kit's dependencies. panel tally 1/4 · reply here or use the finding board to agree/disagree

package-lock.json:3036 · MEDIUM — Missing dependency
The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it.

Fix: Add 'semver' as a dependency in @nuxt/kit's dependencies.

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**`package-lock.json:3036`** · MEDIUM — Missing dependency The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it. > **Fix:** Add 'semver' as a dependency in @nuxt/kit's dependencies. panel tally 1/4 · reply here or use the finding board to agree/disagree

package-lock.json:3036 · MEDIUM — Missing dependency
The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it.

Fix: Add 'semver' as a dependency in @nuxt/kit's dependencies.

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**`package-lock.json:3036`** · MEDIUM — Missing dependency The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it. > **Fix:** Add 'semver' as a dependency in @nuxt/kit's dependencies. panel tally 1/4 · reply here or use the finding board to agree/disagree

package-lock.json:3036 · MEDIUM — Missing dependency
The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it.

Fix: Add 'semver' as a dependency in @nuxt/kit's dependencies.

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**`package-lock.json:3036`** · MEDIUM — Missing dependency The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it. > **Fix:** Add 'semver' as a dependency in @nuxt/kit's dependencies. panel tally 1/4 · reply here or use the finding board to agree/disagree

package-lock.json:3036 · MEDIUM — Missing dependency
The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it.

Fix: Add 'semver' as a dependency in @nuxt/kit's dependencies.

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**`package-lock.json:3036`** · MEDIUM — Missing dependency The dependency 'semver' is missing from @nuxt/kit's dependencies, which may cause runtime errors if the package expects it. > **Fix:** Add 'semver' as a dependency in @nuxt/kit's dependencies. panel tally 1/4 · reply here or use the finding board to agree/disagree

renovate-bot force-pushed renovate/npm-nuxt-vulnerability from e90b4d6060

baseline-security / baseline (push) Failing after 1m0s

Details

baseline-security / baseline (pull_request) Failing after 1m0s

Details

scan / trivy-fs (push) Failing after 48s

Details

scan / trivy-fs (pull_request) Failing after 46s

Details

ai-review / review (pull_request) Successful in 3m24s

Details

to c1a6e43940

scan / trivy-fs (push) Failing after 1m28s

Details

baseline-security / baseline (push) Failing after 1m39s

Details

baseline-security / baseline (pull_request) Failing after 1m23s

Details

scan / trivy-fs (pull_request) Failing after 48s

Details

ai-review / review (pull_request) Successful in 3m49s

Details

2026-08-10 05:08:46 +00:00

Compare

ai-review-bot reviewed

2026-08-10 05:20:30 +00:00

ai-review-bot left a comment

AI review · advisory

Verdict: 1 thing worth fixing (1 high).

Findings that didn't map to a diff line:

package-lock.json:2120 · HIGH — Undici version requires unsupported Node version
The updated undici dependency (v8.10.0) declares a minimum Node engine of >=22.19.0, which is higher than the project's supported Node versions (>=18), causing potential runtime failures and CI breakage.

Fix: Pin undici to a version compatible with Node >=18 (e.g., "undici": "8.8.0") or upgrade the project’s Node engine requirement to >=22.19.0.

package-lock.json:2742 · MEDIUM — Dependency version mismatch
The version of @nuxt/devtools-kit in the dependencies does not match the version in the packages section.

Fix: Update the version of @nuxt/devtools-kit in the dependencies to match the version in the packages section (3.4.1).

package-lock.json:3094 · MEDIUM — Dependency version mismatch
The version of @nuxt/nitro-server in the dependencies does not match the version in the packages section.

Fix: Update the version of @nuxt/nitro-server in the dependencies to match the version in the packages section (4.5.1).

package-lock.json:3460 · MEDIUM — Dependency version mismatch
The version of @nuxt/vite-builder in the dependencies does not match the version in the packages section.

Fix: Update the version of @nuxt/vite-builder in the dependencies to match the version in the packages section (4.5.1).

package-lock.json:3231 · MEDIUM — Dependency version mismatch
The version of @nuxt/schema in the dependencies does not match the version in the packages section.

Fix: Update the version of @nuxt/schema in the dependencies to match the version in the packages section (4.5.1).

_{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 9 distinct, 1 confirmed, 0 refuted · web: not used · context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)}

Panel debate — how this review was reached

Grounding — context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)

Round 1 — independent reviews

GPT-OSS 120B (1 finding, confidence 0.94): The dependency update introduces an incompatible Node engine requirement for undici; downgrade or adjust Node version accordingly.
Gemma 4 31B (0 findings, confidence 1.0): The diff consists exclusively of updates to package-lock.json to bump nuxt to v4.5.1 and its associated dependency tree, including a version bump of the root package; no logic or configuration changes
Devstral 2 123B (8 findings, confidence 0.8): The package-lock.json file has several version mismatches and removed libc entries that may affect compatibility.
Laguna S 2.1 (0 findings, confidence 0.95): Diff is a routine lockfile bump from the nuxt 4.5.1 security update plus a package version bump to 1.7.0; all changes are mechanical dependency-resolution updates confined to package-lock.json with no

Round 2 — cross-examination

GPT-OSS 120B#1 Undici version requires unsupported Node version · confirmed: Gemma 4 31B, Devstral 2 123B · refuted: —
Devstral 2 123B#3 Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#5 Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#7 Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#6 Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#4 Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#8 Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#1 Version mismatch in package-lock.json · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B
Devstral 2 123B#2 Removed libc entries · confirmed: — · refuted: Gemma 4 31B

Synthesis — Devstral 2 123B wrote the final review from 1 confirmed finding (+8 unconfirmed).

_{Transcript rv-20260810051754-1b070e — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.}

_{Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript rv-20260810051754-1b070e.}

### AI review · advisory **Verdict: 1 thing worth fixing** (1 high). Findings that didn't map to a diff line: **`package-lock.json:2120`** · HIGH — Undici version requires unsupported Node version The updated undici dependency (v8.10.0) declares a minimum Node engine of >=22.19.0, which is higher than the project's supported Node versions (>=18), causing potential runtime failures and CI breakage. > **Fix:** Pin undici to a version compatible with Node >=18 (e.g., "undici": "8.8.0") or upgrade the project’s Node engine requirement to >=22.19.0. **`package-lock.json:2742`** · MEDIUM — Dependency version mismatch The version of @nuxt/devtools-kit in the dependencies does not match the version in the packages section. > **Fix:** Update the version of @nuxt/devtools-kit in the dependencies to match the version in the packages section (3.4.1). **`package-lock.json:3094`** · MEDIUM — Dependency version mismatch The version of @nuxt/nitro-server in the dependencies does not match the version in the packages section. > **Fix:** Update the version of @nuxt/nitro-server in the dependencies to match the version in the packages section (4.5.1). **`package-lock.json:3460`** · MEDIUM — Dependency version mismatch The version of @nuxt/vite-builder in the dependencies does not match the version in the packages section. > **Fix:** Update the version of @nuxt/vite-builder in the dependencies to match the version in the packages section (4.5.1). **`package-lock.json:3231`** · MEDIUM — Dependency version mismatch The version of @nuxt/schema in the dependencies does not match the version in the packages section. > **Fix:** Update the version of @nuxt/schema in the dependencies to match the version in the packages section (4.5.1). ⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 9 distinct, 1 confirmed, 0 refuted · web: not used · context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) <details> <summary>Panel debate — how this review was reached</summary> **Grounding** — context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) **Round 1 — independent reviews** - **GPT-OSS 120B** (1 finding, confidence 0.94): The dependency update introduces an incompatible Node engine requirement for undici; downgrade or adjust Node version accordingly. - **Gemma 4 31B** (0 findings, confidence 1.0): The diff consists exclusively of updates to package-lock.json to bump nuxt to v4.5.1 and its associated dependency tree, including a version bump of the root package; no logic or configuration changes - **Devstral 2 123B** (8 findings, confidence 0.8): The package-lock.json file has several version mismatches and removed libc entries that may affect compatibility. - **Laguna S 2.1** (0 findings, confidence 0.95): Diff is a routine lockfile bump from the nuxt 4.5.1 security update plus a package version bump to 1.7.0; all changes are mechanical dependency-resolution updates confined to package-lock.json with no **Round 2 — cross-examination** - `GPT-OSS 120B#1` Undici version requires unsupported Node version · confirmed: Gemma 4 31B, Devstral 2 123B · refuted: — - `Devstral 2 123B#3` Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#5` Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#7` Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#6` Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#4` Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#8` Dependency version mismatch · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#1` Version mismatch in package-lock.json · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B - `Devstral 2 123B#2` Removed libc entries · confirmed: — · refuted: Gemma 4 31B **Synthesis** — Devstral 2 123B wrote the final review from 1 confirmed finding (+8 unconfirmed). Transcript `rv-20260810051754-1b070e` — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway. </details> Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript `rv-20260810051754-1b070e`.

package-lock.json

					
				@ -1,12 +1,12 @@

				{

MEDIUM — Version mismatch in package-lock.json

The version in the root of package-lock.json does not match the version in the packages section.

Fix: Update the version in the root of package-lock.json to match the version in the packages section (1.7.0).

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**MEDIUM** — Version mismatch in package-lock.json The version in the root of package-lock.json does not match the version in the packages section. > **Fix:** Update the version in the root of package-lock.json to match the version in the packages section (1.7.0). panel tally 1/4 · reply here or use the finding board to agree/disagree

package-lock.json

					
				@ -1843,9 +1843,6 @@

				      "cpu": [

LOW — Removed libc entries

The libc entries have been removed from the package-lock.json file, which may affect the compatibility of the package on different systems.

Fix: Consider adding the libc entries back to ensure compatibility across different systems.

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**LOW** — Removed libc entries The libc entries have been removed from the package-lock.json file, which may affect the compatibility of the package on different systems. > **Fix:** Consider adding the libc entries back to ensure compatibility across different systems. panel tally 1/4 · reply here or use the finding board to agree/disagree

package-lock.json

					
				@ -3067,3 +3019,3 @@

				        "destr": "^2.0.5",

				        "devalue": "^5.8.1",

				        "devalue": "^5.8.2",

				        "errx": "^0.1.0",

MEDIUM — Dependency version mismatch

The version of @nuxt/kit in the dependencies does not match the version in the packages section.

Fix: Update the version of @nuxt/kit in the dependencies to match the version in the packages section (4.5.1).

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**MEDIUM** — Dependency version mismatch The version of @nuxt/kit in the dependencies does not match the version in the packages section. > **Fix:** Update the version of @nuxt/kit in the dependencies to match the version in the packages section (4.5.1). panel tally 1/4 · reply here or use the finding board to agree/disagree

package-lock.json

					
				@ -16139,1 +15973,4 @@

				      "version": "4.1.0",

				      "resolved": "https://registry.npmjs.org/birpc/-/birpc-4.1.0.tgz",

				      "integrity": "sha512-O8L9vALWGqdEe0cG4HJckauw3WeJETlJnDRPUYpgwB7wrU43b/5NGMdVjdVcRo+4ROgd3ih2wha1glDe4HRVgw==",

				      "license": "MIT",

MEDIUM — Dependency version mismatch

The version of nuxt in the dependencies does not match the version in the packages section.

Fix: Update the version of nuxt in the dependencies to match the version in the packages section (4.5.1).

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**MEDIUM** — Dependency version mismatch The version of nuxt in the dependencies does not match the version in the packages section. > **Fix:** Update the version of nuxt in the dependencies to match the version in the packages section (4.5.1). panel tally 1/4 · reply here or use the finding board to agree/disagree

A-Guevara commented

2026-08-12 16:18:14 +00:00

Admin-merging: this security fix cannot go green because the required baseline gate fails on the pre-existing tree backlog it is part of fixing (deadlock documented in #28). Lockfile-only bump, reviewed.