high

CVE

CVE-2026-44488

CWE

CWE-770

Affected Surface

axios >= 1.7.0 and < 1.16.0, Node.js services using adapter: 'fetch', Applications with finite maxContentLength or maxBodyLength values, Server-side proxies and gateways that forward attacker-controlled bodies through axios

Axios disclosed CVE-2026-44488 on 4 June 2026. The issue is a size-limit bypass in the library’s fetch adapter: applications that configured finite maxContentLength or maxBodyLength values expected axios to reject oversized request and response bodies, but vulnerable versions allowed those limits to be ignored when the fetch code path was used.

Corgea detected this flaw as part of ongoing dependency monitoring. The advisory is rated high severity with a CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The impact is availability-only. There is no confidentiality or integrity compromise, but server-side services that treated axios size limits as a hard boundary against untrusted input can be driven into memory, CPU, or network exhaustion.

Affected versions

Affected npm package:

  • axios versions >= 1.7.0 and < 1.16.0

Patched version:

  • axios 1.16.0

The fetch adapter was introduced in the 1.7.0 line. Versions before that release are not affected because they did not ship the vulnerable adapter. The default Node.js http adapter enforces both limits and is not part of this advisory.

Teams should check direct and transitive dependencies:

npm ls axios

Many services do not import axios directly but receive it through API clients, SDK wrappers, and internal HTTP utility layers.

What breaks

Axios exposes two related size controls:

  • maxBodyLength limits outbound request body size.
  • maxContentLength limits inbound response body size.

Both default to -1, which means unlimited. The vulnerability does not change axios’s default behavior. It matters when an application sets finite values and expects axios to enforce them as a defense against oversized traffic.

In vulnerable versions, lib/adapters/fetch.js destructured request config without reading maxContentLength or maxBodyLength. The adapter then:

  1. Dispatched fetch() without checking outbound body size.
  2. Materialized the response through text(), arrayBuffer(), blob(), or related resolvers without comparing the result to the configured response limit.

By contrast, the Node.js http adapter already enforced both limits before dispatch and while reading the response stream.

Affected configurations

The fetch adapter path is reached in several real configurations:

  • Explicit adapter: 'fetch'
  • adapter: ['fetch', ...] when fetch is selected
  • Runtimes where neither xhr nor http is available and axios falls back to fetch
  • Custom fetch environments configured through env.fetch

Unaffected configurations include:

  • Default Node.js http adapter usage
  • Versions before the fetch adapter existed
  • Applications that never set finite size limits and do not rely on them as a security control

Browser impact is generally constrained by browser process limits and native fetch behavior. The primary concern is server-side Node.js, Bun, Deno, and edge runtimes where a single process may buffer an entire attacker-controlled body in memory.

Attack scenarios

Three server-side patterns are especially relevant.

Oversized outbound upload

A service forwards attacker-controlled request bodies to a downstream API and sets maxBodyLength to cap what axios will transmit. With the fetch adapter, a 2 MiB body can be sent even when the configured limit is 1 KiB.

Oversized inbound download

A service calls a remote or compromised endpoint and sets maxContentLength to bound how much response data axios will accept. With the fetch adapter, axios can buffer the full response before the application sees an error.

Unbounded data: URL responses

An application accepts user-supplied URLs and passes them to axios with a small maxContentLength. A data: URL can embed kilobytes or megabytes of inline content. Vulnerable versions materialize the decoded payload without enforcing the configured response cap.

In each case, the developer configured a limit that axios documented and enforced on the http adapter. The fetch adapter silently ignored that contract.

Proof of concept

The upstream advisory includes a minimal reproduction for outbound body bypass:

import http from 'node:http';
import axios from 'axios';

const server = http.createServer((req, res) => {
  let received = 0;

  req.on('data', chunk => {
    received += chunk.length;
  });

  req.on('end', () => {
    res.end(JSON.stringify({ received }));
  });
});

await new Promise(resolve => server.listen(0, resolve));
const url = `http://127.0.0.1:${server.address().port}/`;

await axios.post(url, 'A'.repeat(2 * 1024 * 1024), {
  adapter: 'fetch',
  maxBodyLength: 1024
});

// Vulnerable versions succeed and the server receives 2097152 bytes.
// Fixed versions reject with ERR_BAD_REQUEST.

server.close();

On vulnerable axios builds, the POST succeeds and the downstream server receives the full 2 MiB payload. On 1.16.0 and later, axios rejects the request before dispatch.

A related data: URL case from the original report requests a 4 KiB inline payload with maxContentLength: 16. Vulnerable versions return the full decoded body. Fixed versions reject it during upfront size validation.

Root cause and fix

The fix in commit e5540dc added enforcement throughout the fetch adapter:

  • Read maxContentLength and maxBodyLength from config in lib/adapters/fetch.js
  • Upfront decoded-size checks for data: URLs
  • Outbound body-size checks before dispatch
  • Content-Length response pre-checks where available
  • Streaming response enforcement while the body is read
  • Fallback checks for environments without ReadableStream
  • Regression tests in tests/unit/adapters/fetch.test.js

The important design lesson is adapter parity. Axios documents global size limits, but only the http adapter honored them. Any multi-adapter HTTP client that exposes security-relevant configuration must enforce the same limits on every code path, not only the default one.

Remediation

Upgrade axios to a fixed release:

npm install axios@^1.16.0

Verify the resolved tree:

npm ls axios

If a transitive dependency pins an affected version, update the parent package or use the repo’s established package-manager override mechanism until upstream dependencies catch up.

Workarounds before patching

If an immediate upgrade is not possible:

  • Use the Node.js http adapter for server-side requests where finite size limits are security-relevant.
  • Validate or cap attacker-controlled request bodies before passing them to axios.
  • Reject or strictly allowlist attacker-controlled URL schemes, especially data: URLs, before calling axios.

Workarounds reduce exposure but do not replace patching. Adapter selection can change across runtime, bundler, and test environments.

Detection and response

Search code and configuration for axios usage with finite limits:

maxContentLength
maxBodyLength
adapter: 'fetch'
adapter: ['fetch'
env.fetch

Pay special attention to:

  • API gateways and BFF layers that proxy user uploads
  • Webhook delivery workers that fetch user-supplied URLs
  • SSR runtimes that adopted the fetch adapter for edge compatibility
  • Test suites that force adapter: 'fetch' without mirroring production adapter choice

In dependency manifests and deployed artifacts, inventory every resolved axios version below 1.16.0. For services that processed untrusted bodies or URLs through the fetch adapter while relying on size limits, review memory and CPU spikes during the exposure window and inspect outbound traffic for unusually large forwarded payloads.

Teams can pair dependency review with Corgea AI SAST to catch cases where security-sensitive HTTP configuration is set in one layer but a different adapter path is selected at runtime.

Why this matters beyond axios

axios is one of the most common HTTP clients in JavaScript dependency graphs. The vulnerability is not a novel protocol flaw. It is a configuration-enforcement gap between adapters in a library many teams treat as infrastructure.

That pattern shows up elsewhere: a security control is documented at the API surface, enforced on the default path, and silently absent on an alternate execution path introduced for compatibility or performance. For defenders, the actionable takeaway is to verify enforcement on the adapter your production runtime actually uses, not only the one your README examples show.

References