EUVD-2026-53644
GHSA-hxcr-hm88-mpq6
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable with no authentication; single request triggers OOM crash; no confidentiality or integrity impact applies.
Primary rating from Vendor (https://github.com/nuxt/nuxt).
CVSS VectorVendor: https://github.com/nuxt/nuxt
Lifecycle Timeline
3DescriptionCVE.org
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)
AnalysisAI
Unauthenticated remote denial-of-service in Nuxt's island/server-component SSR engine allows any attacker to crash a worker process with a single ~130-byte HTTP request. The island URL hash is a non-secret digest computed from public request parameters, so an attacker can forge valid island requests and supply an arbitrarily large integer as a v-for iteration prop - causing the SSR engine to allocate memory proportional to that integer. Reporter-confirmed measurements show count=40000000 or items=4000000 produces an out-of-memory worker crash; no public exploit code has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the attack is self-evident and trivially reproducible from the advisory description.
Technical ContextAI
Nuxt's island rendering system exposes a /__nuxt_island/ HTTP endpoint that renders isolated Vue server components in response to client requests. Each island request includes a hash derived from the component name and serialized props - but this hash is a non-secret deterministic digest, not an HMAC, so any requester can compute valid hashes for arbitrary prop payloads. When an island component uses v-for over a prop (e.g., v-for="n in count"), Vue's ssrRenderList (for plain v-for) or Nuxt's vforToArray helper (for <slot v-for>) expands the iteration without any upper bound, allocating server memory proportional to the attacker-controlled integer. CWE-400 (Uncontrolled Resource Consumption) precisely describes the root cause: no guard existed at the render boundary to cap iteration count before the fix. Affected packages are pkg:npm/nuxt versions 3.1.0-3.21.9 and 4.0.0-4.5.0. The fix introduces MAX_VFOR_LENGTH = 100000 in packages/nuxt/src/app/components/vfor.ts and accompanying body-size and depth guards in the island handler.
RemediationAI
Upgrade to nuxt@4.5.1 (Nuxt 4.x) or nuxt@3.21.10 (Nuxt 3.x) immediately; these releases introduce MAX_VFOR_LENGTH = 100000, clamping v-for iteration at the render boundary across all affected paths, and add body-size (64 KB) and nesting-depth (64 levels) guards on island requests. Patch commits are at https://github.com/nuxt/nuxt/commit/4e35ae9babd94be53246e31200232d48438bb34e and https://github.com/nuxt/nuxt/commit/668cdfdfda41849ed11c1ee5e2067a11fc103b22. If an immediate upgrade is not feasible, clamp iteration count inside each affected component using v-for="n in Math.min(count, 1000)" - this eliminates the integer-amplification vector but requires auditing every island component individually. A reverse-proxy body-size limit on /__nuxt_island/ requests mitigates array-shaped inputs (where the attacker sends a large array), but critically does NOT prevent the integer-amplification case: a single 130-byte request carrying a large integer passes any reasonable body-size check. In-component clamping or the upstream patch are therefore the only complete mitigations.
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today