CVE-2026-71321: Unauthenticated Denial of Service and CPU Exhaustion in Nuxt Island Renderer

Nuxt Server Components, known as Islands, render dynamically on the server side to support localized interactive blocks within a web application. The server manages these components through an internal endpoint located at /__nuxt_island/. This architecture allows clients to fetch up-to-date server-side rendered markup by passing specific component parameters, props, and a validation hash.

Because the framework must allow dynamic property updates, the endpoint accepts user-provided structures to re-render the components. An unauthenticated attacker can target this endpoint to transmit malformed input payloads. Since Nuxt utilizes the single-threaded Node.js and Nitro server environments, executing computationally expensive parsing operations directly blocks the event loop.

The vulnerability, tracked as CVE-2026-71321, stems from the validation order of operations. The system processes the incoming request body, parses the JSON data, and computes its cryptographic hash prior to verifying whether the client holds a valid authorization signature. This execution sequence allows unauthenticated, remote attackers to exhaust CPU resources with minimal effort.

The fundamental flaw in Nuxt resides in its verification sequence within the island request handler. When a POST request arrives at the internal endpoint /__nuxt_island/..., the handler immediately calls readBody() to retrieve the raw request. At this early stage, the framework performs no validation on the request content size, complexity, or structural properties.

After retrieving the body, the handler passes the payload to destr, an optimized JSON-parsing library. It subsequently runs the resulting JavaScript object through ohash, a hashing library, to calculate the signature. This cryptographic hashing mechanism operates on all key-value pairs inside the dynamic component properties (props).

Only after completing these parsing and hashing cycles does the system compare the computed signature with the hash identifier provided in the URL. If the signature is incorrect, the server throws an HTTP 400 error. However, because both JSON parsing and hashing are CPU-bound operations executing synchronously on the main event loop, the server's compute time is already spent, causing event loop starvation.

Additionally, server-side template compilation introduced another resource-exhaustion vector. When dynamic components employ a numeric iteration directive like <div v-for="n in count"> using dynamic prop parameters, an attacker can specify a high iteration range. The server attempts to generate and render millions of DOM elements dynamically, leading to memory depletion and process termination.

The patches introduced in commits 4e35ae9babd94be53246e31200232d48438bb34e and 668cdfdfda41849ed11c1ee5e2067a11fc103b22 rewrite the request handling to prevent premature parsing. In the corrected code, the handler leverages a new guarding method named readGuardedIslandBody. This method checks the Content-Length header before buffering any data, throwing an immediate HTTP 413 error if the length exceeds 64KB.

To safeguard against chunked encoding requests that bypass content length headers, the patch processes incoming data via web streams. It increments a running byte counter as it processes stream chunks, aborting the transfer if the cumulative size crosses the 64KB limit. It also integrates a linear-scan check to ensure structural depth remains bounded.

// Linear depth scanning prevents stack overflow and recursive exhaustion
export function exceedsMaxDepth (raw: string, maxDepth = 64): boolean {
  let depth = 0
  let inString = false
  let escaped = false
  for (let i = 0; i < raw.length; i++) {
    const ch = raw[i]
    if (inString) {
      if (escaped) { escaped = false } 
      else if (ch === '\\\\') { escaped = true }
      else if (ch === '\"') { inString = false }
      continue
    }
    if (ch === '\"') { inString = true }
    else if (ch === '{' || ch === '[') {
      if (++depth > maxDepth) { return true }
    } else if (ch === '}' || ch === ']') {
      if (depth > 0) { depth-- }
    }
  }
  return false
}

This depth-limiting parser prevents nested object attacks without running the complete, recursive parsing logic. For the dynamic iteration vector, the framework implements a build-time and runtime clamp named vforBound. This function restricts the iteration length to a maximum of 10,000 passes, successfully neutralizing memory amplification attacks.

Exploiting CVE-2026-71321 requires no authentication or specific session state. Because the internal island endpoint remains exposed by default, any client can send HTTP POST requests directly to the application server. The attacker needs to generate an oversized or highly nested JSON body to initiate the exhaustion sequence.

A typical attack construct sends a massive, flat JSON dictionary containing thousands of keys to maximize hashing overhead. Alternatively, the attacker can submit deeply nested arrays like [[[[...]]]] to stress the deserializer. In both scenarios, the server blocks on the synchronous parsing call, preventing any concurrent HTTP requests from being processed on the single-threaded event loop.

The attack remains highly efficient for the adversary. Generating and sending a 4.6 MB text payload requires minimal network overhead, yet it forces the target Node.js process to consume high CPU cycles for hundreds of milliseconds. By sending several dozen concurrent requests per second, a single machine can achieve complete denial of service across the entire application interface.

The CVSS score of 7.5 reflects the severe impact this vulnerability has on application availability. Because the main thread in a Node.js process is shared across all incoming connections, blocking this thread impacts the entire environment. All legitimate users experiencing the attack face severe latency or complete request timeouts.

The lack of authentication requirements broadens the risk profile. The internal endpoint does not implement rate-limiting or validation guards by default, exposing internal APIs directly to the public web. Automated scanning tools can easily detect the vulnerability without complex configurations.

While the flaw does not permit arbitrary code execution or data exposure, its impact on operational availability is absolute. If deployed in critical cloud environments without isolated container controls, a prolonged denial of service can trigger automatic scaling rules. This behavior can result in unexpected cloud compute costs, compounding the operational damage.

The primary remediation path requires upgrading Nuxt to version 3.21.10 or 4.5.1. These versions successfully isolate the parsing logic behind early size and depth validations, rendering DoS payloads ineffective. Upgrading resolves both the pre-parsing CPU exhaustion and the numeric loop memory issues.

Defenders can verify vulnerability status passively by sending a body larger than 64KB containing a structured invalid signature. If the server evaluates the request and responds with an HTTP 400 status, it has processed the payload, indicating a vulnerable configuration. Conversely, a patched server will abort the request early, returning an HTTP 413 Payload Too Large error.

If immediate deployment upgrades are not possible, administrators should configure request limits on their reverse proxy or web application firewall. Applying a strict 10KB size limit to the prefix path /__nuxt_island/ blocks malicious payloads before they reach the Node.js runtime. This configuration prevents CPU exploitation without interrupting legitimate island rendering features.