Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable endpoint, no authentication or special conditions required, single-event-loop stall causes high availability impact with no confidentiality or integrity effect.
Primary rating from Vendor (https://github.com/nuxt/nuxt).
CVSS VectorVendor: https://github.com/nuxt/nuxt
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Unauthenticated CPU exhaustion in Nuxt's island renderer endpoint allows remote attackers to degrade or stall server availability without any credentials or valid hash. Nuxt versions 3.1.0-3.21.9 and 4.0.0-4.5.0 are affected: the /__nuxt_island/ handler fully buffers, destr-parses, and ohash-hashes attacker-supplied POST bodies before checking the URL-embedded hash token, meaning expensive computation runs on doomed requests. Because Nitro's runtime executes on a single Node.js event loop, a sustained low-rate flood of ~4.6 MB JSON bodies is sufficient to stall all concurrent legitimate requests. No public exploit code or CISA KEV listing exists, but the attack is trivially reproducible from the published advisory description alone.
Technical ContextAI
Nuxt (npm/nuxt) exposes a /__nuxt_island/<name>_<hash>.json HTTP endpoint as part of its server-component (island) rendering architecture, powered by the Nitro server runtime. In vulnerable versions, the endpoint's handler first reads the entire POST body via h3, passes it to destr (a zero-dependency JSON deserializer), then computes a hash with ohash - all before validating the URL-embedded hash token that would authorize the request. CWE-407 (Algorithmic Complexity - Inefficient Algorithmic Complexity) precisely describes the root cause: the parsing and hashing operations scale linearly with input size, and there was no prior bound on attacker-supplied input. Nitro runs all request handlers on a single-threaded Node.js event loop; synchronous CPU work on one request delays every concurrently pending request. The fix (commits 4e35ae9 and 668cdfd) introduces a new island-props.ts utility enforcing a 64 KB raw body cap (MAX_ISLAND_BODY_BYTES) and a 64-level JSON nesting cap (MAX_ISLAND_PROP_DEPTH), both checked via streaming reads and a single-pass bracket counter before any parse or hash operation runs.
RemediationAI
Upgrade to nuxt@4.5.1 for v4 users or nuxt@3.21.10 for v3 users; both releases are confirmed by GitHub advisory GHSA-9pgf-384g-p7mv (https://github.com/nuxt/nuxt/security/advisories/GHSA-9pgf-384g-p7mv) and available via npm. If immediate patching is not possible, configure a request body-size limit of approximately 64 KB at your reverse proxy or edge layer specifically for requests matching the path /__nuxt_island/; this mirrors the patch's own cap (MAX_ISLAND_BODY_BYTES = 64 * 1024) and has negligible impact on legitimate island traffic, which only carries compact props payloads - the trade-off is that it requires infrastructure access and may need adjustment if any island component legitimately sends larger props. Alternatively, if server components (islands) are not actively in use, disable the feature entirely to remove the endpoint from the attack surface; the trade-off is loss of server-component rendering capability.
Same weakness CWE-407 – Inefficient Algorithmic Complexity
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-53658
GHSA-9pgf-384g-p7mv