CVE-2026-71321

This is a pre-validation resource exhaustion flaw that exploits Nitro's single-threaded event loop, and it's more dangerous in serverless environments than typical ReDoS vulnerabilities. The vulnerability lives in the `/__nuxt_island` endpoint. When processing requests, Nitro parses the JSON body using `destr`, then computes an `ohash` hash of that body — and only then validates the hash parameter against the computed value. Because this happens on a single-threaded event loop, a malicious request with a sufficiently large JSON body consumes CPU cycles before the hash is ever checked. A single request can block all concurrent connections. What makes this particularly nasty in serverless: CPU time is metered independently of wall-clock time. In Cloudflare Workers, AWS Lambda@Edge, or similar environments with strict per-invocation CPU budgets, a request consuming 400ms of CPU in a 400ms budget causes function timeout — not just delay. Traditional DoS defenses (rate limiting, payload size caps) often miss this because each request is syntactically valid; it just takes too long to process. The `ohash` algorithm matters here. It's optimized for speed — a non-cryptographic checksum (xxhash derivative) designed for fast comparison and caching, not security. This makes CPU consumption highly predictable and calibratable: an attacker can tune payload size to consume exact CPU budget without triggering mid-operation timeouts. The hash validation was likely a cache-integrity mechanism that got accidentally repurposed as a security control. The exploitation path matters: `/__nuxt_island` is an internal SSR rendering endpoint. In production it's typically behind authentication or routing layers. This vulnerability becomes exploitable when paired with SSRF, subdomain takeover, or any mechanism allowing an attacker to elicit server-side requests to the island endpoint. Credentialed attacks could target specific users or tenants rather than causing broad infrastructure DoS. The fix in Nitro 3.21.10 and 4.5.1 is straightforward: validate the hash before parsing the JSON body, rejecting invalid hashes immediately. But in serverless environments with auto-scaling, cold starts on vulnerable instances can persist even after the fix is deployed — every new instance is a potential exploitation vector until the deployment fully propagates. Check your deployed Nitro version. Monitor for unusual `/__nuxt_island` request patterns from non-origin IPs. Consider adding parsing budgets or worker isolation as defense-in-depth, since operation-ordering bugs of this type have a documented history across multiple languages and frameworks.

Reviewed through automated stages and approved by a human before publication.