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

• npm nuxt: >= 4.0.0, < 4.5.1 → fixed in 4.5.1 • npm nuxt: >= 3.1.0, < 3.21.10 → fixed in 3.21.10

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 ``). 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 `[email protected]` and `[email protected]`. 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 `` 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`)