CVE-2026-42036: maxContentLength Bypass and Resource Exhaustion in Axios

Axios is a promise-based HTTP client for the browser and Node.js. It provides the maxContentLength configuration option to protect applications from unbounded responses by defining a maximum acceptable response body size. This mechanism is critical for preventing resource exhaustion when interacting with untrusted external servers.

Prior to versions 1.15.1 and 0.31.1, the Axios Node.js adapter fails to enforce the maxContentLength limit when a request specifies responseType: 'stream'. The library returns the response stream to the caller without applying the byte-counting constraints that are normally enforced for buffered response types.

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). By serving an infinite or excessively large data stream, a malicious server can bypass the intended safety boundaries of the Axios client. This condition allows unbounded downstream consumption, leading to local resource exhaustion.

The root cause resides in the Axios Node.js HTTP adapter implementation (lib/adapters/http.js). The library enforces maxContentLength within the code path responsible for buffering response data. When handling standard response types like json, text, or arraybuffer, Axios aggregates data chunks into memory and continuously verifies the cumulative byte count against the configured threshold.

When responseType: 'stream' is used, the HTTP adapter delegates the request to the follow-redirects package, which acts as a wrapper for the native Node.js http and https modules. Upon receiving the initial HTTP response headers, Axios immediately resolves the request promise. This returns the raw IncomingMessage object, which implements the ReadableStream interface, directly to the calling application.

Because the promise settles before data consumption begins, Axios bypasses the buffering logic entirely. Consequently, the byte-counting enforcement mechanism is never engaged. The application receives a raw stream that continues to emit data events regardless of the maxContentLength configuration, effectively shifting the responsibility of size validation to the downstream consumer.

The vulnerability is patched by updating the underlying follow-redirects dependency to version 1.16.0. Axios relies on follow-redirects for native HTTP/HTTPS handling and redirection logic. The vulnerability ultimately stems from a lack of stream-level size enforcement within this dependency chain when passing the raw socket to the caller.

In the vulnerable configuration, Axios initiates the request but does not inject stream-level constraints into the returned IncomingMessage. The fix in commit 770f5ef0811fc6ec8e7cea4ff40eb83542957bc3 bumps the follow-redirects dependency. The updated follow-redirects version implements internal byte-monitoring logic associated with its maxBodyLength parameter, which maps directly to the Axios maxContentLength configuration.

With the dependency updated, follow-redirects enforces the byte limit directly on the socket stream. When the received byte count exceeds the threshold, the library emits a 'maxBodyLength exceeded' error and proactively destroys the underlying TCP socket. This prevents the Node.js process from continuing to download the oversized payload.

// Package lock structural change reflecting the mitigation
// Vulnerable
"dependencies": {
  "follow-redirects": "^1.15.0"
}
 
// Patched
"dependencies": {
  "follow-redirects": "^1.15.6" // Resolves to >= 1.16.0 containing the fix
}

Exploitation requires the attacker to control the HTTP server responding to an Axios client request. The target application must explicitly configure the Axios request with responseType: 'stream' and define a maxContentLength value. This setup is common in applications that proxy downloads or process large files iteratively to save memory.

The attacker configures their malicious HTTP server to accept incoming connections and respond with an endless stream of garbage data or a payload significantly larger than the expected file size. Because the client library fails to terminate the connection upon reaching the maxContentLength limit, the server can sustain the data transmission indefinitely.

> [!NOTE] > A standard Node.js server using res.write() in a continuous loop is sufficient to trigger the vulnerability.

The Axios client resolves the response promise upon receiving the headers and passes the stream to the application logic. The application processes the incoming data chunks, resulting in sustained CPU usage, memory accumulation, or disk space consumption depending on how the application handles the emitted data.

The primary security impact is Denial of Service (DoS) through resource exhaustion. Depending on how the application handles the returned stream, an attacker can exhaust different system resources. The CVSS v3.1 base score is 5.3 (Medium), reflecting a partial loss of availability with no confidentiality or integrity impact.

If the application pipes the Axios response stream directly to the local filesystem using fs.createWriteStream, an attacker can exhaust available disk space. This can lead to system-wide instability, preventing logging mechanisms, databases, and other applications from functioning correctly.

If the downstream application buffers the stream chunks into memory, the attack will cause rapid memory consumption, eventually triggering an Out-Of-Memory (OOM) crash in the Node.js process. Continuous processing of an endless stream also monopolizes the event loop, causing CPU exhaustion and degrading the application's ability to service legitimate requests.

The official remediation is to update the Axios library to a patched version. Maintainers released versions 1.15.1 and 0.31.1 to address the vulnerability. These releases include the necessary dependency updates to follow-redirects that introduce native stream-level size enforcement.

For environments where immediate upgrading is not feasible, developers must implement a manual stream wrapper. This involves piping the Axios response stream through a custom Transform stream that increments a byte counter on each chunk. If the counter exceeds the expected limit, the custom stream must call stream.destroy() on the incoming response to terminate the TCP connection immediately.

Developers should ensure that downstream consumers of Axios streams implement their own resource constraints. Relying solely on the HTTP client for size validation is insufficient defense-in-depth. All file system writes and memory buffers handling external data must enforce strict maximum size policies.