Axios Fetch Adapter Size Limit Bypass (CVE-2026-44488): Technical Breakdown with PoC and Patch Analysis

Introduction

The Axios HTTP client library, which has over 70 million weekly npm downloads, shipped a fetch adapter that for nearly two years completely ignored configured request and response size limits. CVE-2026-44488 (CVSS 7.5 High) shows that any server-side application relying on maxContentLength or maxBodyLength while using the fetch adapter had no effective size control at all. Oversized payloads could exhaust its resources.

The disclosure arrives just months after the axios npm package suffered a supply-chain compromise attributed to the North Korean state actor Sapphire Sleet. That makes it the second major security event for the project in 2026. Organizations have one more reason to audit their axios deployments closely.

Technical Information

Root Cause: Adapter Parity Failure

CVE-2026-44488 is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The vulnerability comes from an implementation gap between axios's two HTTP adapters. The Node.js http adapter has long enforced the maxContentLength and maxBodyLength configuration options and rejects oversized payloads before they can consume resources. When the fetch adapter was introduced in version 1.7.0, the equivalent enforcement logic was never implemented. The lib/adapters/fetch.js module never destructured or checked these configuration values before dispatching requests or materializing responses.

The size-limit code paths were missing from the fetch adapter entirely. Any application that set maxBodyLength: 1024 or maxContentLength: 50000 was operating under a false sense of security whenever the fetch adapter was active.

How the Fetch Adapter Gets Selected

The fetch adapter can become active in two ways:

1. Explicit selection: The application sets adapter: 'fetch' in the axios request configuration.
2. Implicit resolution: Axios runs in an environment where the native fetch API is available (modern Node.js versions, Bun, Deno, edge runtimes) and the library resolves to the fetch adapter by default.

The implicit path means an application can be vulnerable even though no developer ever chose the fetch adapter. This is especially relevant for teams migrating to newer Node.js versions or deploying to edge/serverless runtimes where fetch is the native HTTP primitive.

Attack Vectors

The upstream advisory documents three exploitation scenarios:

1. Malicious Server, Oversized Response: An attacker controls or compromises a server that an axios client communicates with. The server returns a response body far larger than the configured maxContentLength. The fetch adapter never checks this limit, so it buffers the entire response into memory, which can crash the process or cause out-of-memory conditions.

2. Large data: URL: An attacker supplies a data: URL (for example, through a user-controlled input field that accepts URLs) whose decoded content exceeds maxContentLength. The fetch adapter materializes the full payload without validating its size.

3. Attacker-Controlled Request Body Forwarding: An application accepts user-supplied data, forwards it through axios (common in BFF layers, API gateways, and webhook delivery systems), and relies on maxBodyLength to cap outbound payload size. The fetch adapter transmits the full body regardless of the configured limit, which can exhaust outbound bandwidth or overload the downstream server.

CVSS Breakdown

The CVSS v3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H breaks down as follows:

Proof of Concept

The upstream GitHub Security Advisory (GHSA-777c-7fjr-54vf) publishes a proof of concept directly. Corgea research has reproduced it, and it is mirrored on OSV.dev and Miggo.

The PoC sets up a local HTTP server, then sends a 2 MiB POST body through Axios with the fetch adapter while maxBodyLength is set to only 1024 bytes. On vulnerable versions, the request succeeds and the server receives all 2,097,152 bytes. On fixed versions (1.16.0 and later), Axios rejects the request with ERR_BAD_REQUEST before dispatch.

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();

The original report used the Axios main branch at commit f7a4ee2, running on Node.js v24.2.0.

The same advisory includes a second case that bypasses the limit with a data: URL. Requesting a 4 KiB inline data: URL payload with adapter: 'fetch' and maxContentLength: 16 succeeds on vulnerable versions and returns the full 4096-byte decoded body. Fixed versions reject it during upfront size validation.

Patch Information

The fix landed in commit e5540dc, authored by maintainer Jay (jasonsaayman) on April 22, 2026, and shipped in axios v1.16.0 on May 2, 2026. The commit message reads: fix: fetch adaptor is not enforcing max body or content length (#10795).

The patch is substantial, with 280 additions and only 3 deletions across 3 files (lib/adapters/fetch.js, lib/helpers/estimateDataURLDecodedBytes.js, and tests/unit/adapters/fetch.test.js). Instead of a single check, the fix takes a defense-in-depth approach with several enforcement layers:

Config Extraction: The patch destructures maxContentLength and maxBodyLength from the resolved config and precomputes boolean flags that indicate whether finite limits are configured:

const hasMaxContentLength = utils.isNumber(maxContentLength) && maxContentLength > -1;
const hasMaxBodyLength = utils.isNumber(maxBodyLength) && maxBodyLength > -1;

Pre-Flight data: URL Check: Before any network activity, the patch estimates the decoded size of data: URLs with an imported estimateDataURLDecodedBytes helper. If the estimated payload exceeds maxContentLength, the patch throws an ERR_BAD_RESPONSE error immediately.

Outbound Body Size Check: For non-GET/HEAD requests, the patch resolves the outbound body length and compares it against maxBodyLength before dispatching the fetch() call. It rejects oversized payloads with ERR_BAD_REQUEST and the message "Request body larger than maxBodyLength limit," which matches the HTTP adapter's existing error.

Response Content-Length Pre-Check: After fetch() returns but before the body is consumed, the patch reads the Content-Length response header. If the server honestly declares a length over the limit, the patch rejects the response immediately, so it avoids streaming entirely when possible.

Streaming Enforcement: For chunked or streaming responses with no Content-Length, the patch wraps the existing stream progress tracker with a new onChunkProgress callback that keeps a running bytesRead counter. Each chunk increments the counter and checks it against maxContentLength, and the patch throws ERR_BAD_RESPONSE mid-stream if the limit is crossed.

Fallback for Legacy Runtimes: For environments without ReadableStream support, the patch adds a post-materialization check on the response data's byteLength, size, or string length (using TextEncoder or a raw .length fallback).

Cross-Environment estimateDataURLDecodedBytes Fix: The helper previously relied on Node's Buffer.byteLength(), which would fail in browsers. The patch adds a fallback to TextEncoder encoding or raw string length, so the data: URL check works across all JavaScript runtimes.

Tests: The commit adds a dedicated describe('size limits (GHSA-777c-7fjr-54vf)') test suite covering seven scenarios: oversized outbound bodies, responses exceeding Content-Length headers, chunked streaming responses, base64 and non-base64 data: URLs, and positive cases confirming that requests within the limits still succeed.

Detection Methods

Dependency and Version Scanning (SCA)

Software Composition Analysis is the most immediate and reliable detection method. Every major vulnerability database tracks the vulnerable range (>= 1.7.0 and < 1.16.0), including GitHub Advisory Database (GHSA-777c-7fjr-54vf), Snyk (SNYK-JS-AXIOS-17172751), Tenable, and GitLab Dependency Scanning. Tools such as npm audit, GitHub Dependabot, Snyk, and GitLab's built-in dependency scanner automatically flag projects with a vulnerable axios version.

Many applications do not import axios directly. It arrives as a transitive dependency through SDK wrappers, API clients, or internal HTTP utility layers. The command npm ls axios lists every resolved instance of the package, direct and transitive, and is the quickest way to determine exposure in a Node.js project.

Code and Configuration Pattern Auditing

Not every installation of a vulnerable axios version is exploitable. The vulnerability only fires when the fetch adapter is active and the application has configured finite maxContentLength or maxBodyLength values. Corgea's detection guidance recommends searching codebases for the co-occurrence of these configuration keywords:

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

Services that match this pattern and handle untrusted data are the highest-priority targets for review. These include API gateways and BFF (backend-for-frontend) layers that proxy user uploads, webhook delivery workers that fetch user-supplied URLs, and SSR runtimes that adopted the fetch adapter for edge compatibility.

Runtime and Behavioral Monitoring

Exploitation shows up as resource exhaustion, so defenders can look for anomalous runtime behavior. Corgea's advisory specifically calls out two checks for services that processed untrusted bodies or URLs through the fetch adapter: review telemetry for memory and CPU spikes, and inspect outbound traffic for unusually large forwarded payloads. Container orchestrators or APM tools that track per-process memory allocation are well placed to surface these anomalies. A sudden increase in resident set size (RSS) on a Node.js, Bun, or Deno service that handles external input through axios could be a symptom of this bypass being triggered.

WAF-Level Detection

Miggo's vulnerability intelligence page for CVE-2026-44488 says WAF protection rules for the observed attack patterns are available, but only to Miggo customers. No publicly available WAF rule sets for this CVE have been published at the time of writing.

What Is Not Available

No public Snort, Suricata, YARA, or Sigma rules exist for this CVE. There are no known attacker-attributed Indicators of Compromise (IP addresses, domain names, file hashes) tied to exploitation of this size-limit bypass. The Axios-related IoCs publicly reported in early 2026 belong to the separate npm supply-chain compromise and should not be conflated with CVE-2026-44488.

Affected Systems and Versions

Versions prior to 1.7.0 are not affected, because they do not contain the fetch adapter code at all.

The vulnerability is triggered when:

• The fetch adapter is active, either through explicit configuration (adapter: 'fetch') or implicit resolution in environments with native fetch support
• The application has configured finite maxContentLength or maxBodyLength values and expects them to be enforced
• The application processes untrusted data (external URLs, user-supplied request bodies, responses from untrusted servers)

Vendor Security History

Axios has accumulated a significant vulnerability record over the past several years:

Notable recent vulnerabilities include:

• CVE-2025-27152 (CVSS 5.3): An SSRF vulnerability, classified under CWE-918, caused by improper URL parsing when absolute URLs were passed to the library.
• CVE-2026-40175: Rated critical, but Aikido assessed it as not practically exploitable.
• CVE-2026-44488 (CVSS 7.5): The vulnerability covered in this post.

The March 2026 supply-chain compromise is the most severe incident in the project's history. Sapphire Sleet, a North Korean state-sponsored threat actor, compromised the npm maintainer account and published malicious versions ([email protected] and [email protected]) that contained a RAT. The malicious packages were available for approximately 3 hours and 19 minutes. The incident exposed weaknesses in the project's governance. Core contributor DigitalBrainJS lacked the admin permissions to revoke the compromised account's access directly, and the attacker used GitHub admin privileges to unpin and delete an issue in which a community member reported the breach.

Microsoft, Trend Micro, the Singapore Cyber Security Agency, and Cisco Talos all published advisories or analyses of the supply-chain incident.

References

• NVD: CVE-2026-44488
• CVE Record: CVE-2026-44488
• GitHub Security Advisory: GHSA-777c-7fjr-54vf
• GitHub Advisory Database: GHSA-777c-7fjr-54vf
• OSV.dev: GHSA-777c-7fjr-54vf
• Corgea Research: Axios Fetch Size Limits Bypass
• Miggo Vulnerability Database: CVE-2026-44488
• GitLab Advisory: CVE-2026-44488
• Snyk Vulnerability: SNYK-JS-AXIOS-17172751
• Tenable: CVE-2026-44488
• Patch Commit: e5540dc
• Snyk: axios Package Security
• Vulners: GHSA-777c-7fjr-54vf
• Microsoft: Mitigating the Axios npm Supply Chain Compromise
• Trend Micro: Axios NPM Package Compromised
• Open Source Malware: Axios Compromised
• Singapore CSA Advisory: AD-2026-002
• Radical Notion: axios Vulnerabilities
• NVD: CVE-2025-27152
• CISA Known Exploited Vulnerabilities Catalog