CVE-2026-40073: Unrestricted Resource Allocation in SvelteKit adapter-node via Chunked Transfer Encoding

SvelteKit utilizes @sveltejs/adapter-node to generate standalone Node.js servers for deploying server-side rendered applications. The framework enforces a BODY_SIZE_LIMIT (defaulting to 512 kilobytes) to prevent excessively large payloads from exhausting server resources during request processing.

A logic vulnerability exists in how the framework parses specific HTTP requests, neutralizing this safeguard. When an incoming request uses chunked transfer encoding, the underlying body parser fails to accurately account for the accumulating payload size against the configured limit.

This bypass allows unauthenticated remote attackers to stream continuous data to the target endpoint. Because the application logic does not terminate the connection when the payload exceeds the limit, the server buffers the entirety of the malicious payload into memory, causing resource exhaustion.

The vulnerability originates in the get_raw_body function within packages/kit/src/exports/node/index.js. The original implementation relied on the Content-Length HTTP header to determine if an incoming request exceeded the BODY_SIZE_LIMIT parameter.

When an HTTP client uses Transfer-Encoding: chunked, the Content-Length header is omitted by protocol design. The get_raw_body function incorrectly assumed the content_length variable would resolve to a finite numeric value. Instead, the absence of the header caused the parser to assign the variable a value of NaN (Not-a-Number).

The enforcement routine evaluated the accumulated chunk size against the parsed limit using the conditional size > content_length. In the JavaScript specification, any numerical comparison involving NaN strictly evaluates to false. Consequently, the application accepted subsequent data chunks indefinitely, entirely skipping the rejection logic.

The vulnerable implementation coupled the cumulative size check directly to the protocol-provided Content-Length header. The evaluation failed silently due to type coercion anomalies inherent to JavaScript.

// Vulnerable Logic in get_raw_body
size += chunk.length;
if (size > content_length) {
    // condition evaluates to false when content_length is NaN
    // memory buffer continues to grow without restriction
}

The patch implemented in commit 3202ed6c98f9e8d86bf0c4c7ad0f2e273e5e3b95 introduces a decoupled evaluation sequence. The system now validates the absolute size of the accumulated payload against the configured internal limit independently of the client-supplied HTTP headers.

// Patched Logic in get_raw_body
size += chunk.length;
 
// Primary check against configured application limit
if (body_size_limit !== undefined && size > body_size_limit) {
    cancelled = true;
    const message = `request body size exceeded BODY_SIZE_LIMIT of ${body_size_limit}`;
    const error = new SvelteKitError(413, 'Payload Too Large', message);
    controller.error(error);
    return;
}
 
// Secondary check for HTTP protocol consistency
if (has_content_length && size > content_length) {
    cancelled = true;
    // Reject requests that violate their own declared Content-Length
}

An attacker initiates the exploit by opening a persistent HTTP connection to a SvelteKit application utilizing adapter-node. The client sends a POST or PUT request with the Transfer-Encoding: chunked header while deliberately omitting the Content-Length header.

The client subsequently streams data blocks to the server. The attacker does not need to send the final zero-length chunk that typically terminates a chunked sequence. Instead, they supply an ongoing sequence of data blocks that rapidly consume the target application's memory pool.

import http from 'node:http';
 
const req = http.request({
  hostname: 'target.example.com',
  port: 443,
  method: 'POST',
  headers: { 'Transfer-Encoding': 'chunked' }
});
 
// Loop to exhaust server memory
setInterval(() => {
  req.write(Buffer.alloc(1024 * 1024, 'A')); 
}, 10);

Successful exploitation induces rapid resource exhaustion within the Node.js runtime environment. Because the framework allocates unconstrained memory buffers for incoming data, the application memory footprint grows proportionally to the attacker's transmission rate.

Once the memory usage exceeds the maximum heap size allocated to the V8 JavaScript engine, the process terminates with an Out-Of-Memory (OOM) exception. This event drops all concurrent connections and terminates the application service. If the process is not managed by an automated supervisor, the outage remains persistent.

The vulnerability carries a CVSS v4.0 base score of 8.2 (High). The metric evaluates the attack requirements as present, given the target must utilize adapter-node without external WAF-level payload restrictions. The primary impact maps exclusively to systemic availability.

Software engineers must update the @sveltejs/kit dependency to version 2.57.1 or later. Applying this update introduces the decoupled limit verification logic and restores internal protection against anomalous payload sizes.

Organizations should implement defense-in-depth principles by configuring absolute payload limits at the perimeter infrastructure. Administrators must configure reverse proxies, such as Nginx or HAProxy, to enforce connection-level constraints utilizing directives like client_max_body_size.

In environments where immediate patching is unfeasible, operators can mitigate the attack surface by deploying network rules that block unauthenticated requests presenting the Transfer-Encoding: chunked header, provided legitimate client applications do not rely on chunked uploads.