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

Introduction

The Axios HTTP client library, a cornerstone of the JavaScript ecosystem with over 70 million weekly npm downloads, shipped a fetch adapter for nearly two years that completely ignored configured request and response size limits. CVE-2026-44488 (CVSS 7.5 High) reveals that any server side application relying on maxContentLength or maxBodyLength while using the fetch adapter had no effective size control at all, opening the door to resource exhaustion from oversized payloads.

This disclosure arrives just months after the axios npm package suffered a supply chain compromise attributed to the North Korean state actor Sapphire Sleet, making it the second major security event for the project in 2026 and reinforcing the need for organizations to closely audit their axios deployments.

Technical Information

Root Cause: Adapter Parity Failure

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

This is not a subtle race condition or a complex parser differential. The size limit code paths were entirely absent from the fetch adapter. 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, and the second is particularly insidious:

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 applications can be vulnerable without any developer having consciously chosen 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

Three distinct exploitation scenarios are documented in the upstream advisory:

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 exceeding the configured maxContentLength. Because the fetch adapter never checks this limit, the entire response is buffered into memory, potentially causing process crashes or 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 any size validation.

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

CVSS Breakdown

The CVSS v3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H tells us:

Proof of Concept

A public proof of concept is published directly in the upstream GitHub Security Advisory (GHSA-777c-7fjr-54vf) and has been reproduced by Corgea research and 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 environment used in the original report was the Axios main branch at commit f7a4ee2 running on Node.js v24.2.0.

A second PoC case from the same advisory demonstrates a data: URL bypass: requesting a 4 KiB inline data: URL payload with adapter: 'fetch' and maxContentLength: 16 succeeds on vulnerable versions (returning the full 4096 byte decoded body), whereas 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 at 280 additions across 3 files (lib/adapters/fetch.js, lib/helpers/estimateDataURLDecodedBytes.js, and tests/unit/adapters/fetch.test.js) with only 3 deletions. Rather than a single check, the fix implements a defense in depth strategy with multiple enforcement layers:

Config Extraction: The patch destructures maxContentLength and maxBodyLength from the resolved config and pre computes boolean flags indicating 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 using an imported estimateDataURLDecodedBytes helper. If the estimated payload exceeds maxContentLength, an ERR_BAD_RESPONSE error is thrown 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. Oversized payloads are rejected with ERR_BAD_REQUEST and the message "Request body larger than maxBodyLength limit," consistent with 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 exceeding the limit, the response is rejected immediately, avoiding streaming entirely when possible.

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

Fallback for Legacy Runtimes: For environments lacking ReadableStream support, the patch adds a post materialization check inspecting 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 graceful fallback through TextEncoder encoding or raw string length, ensuring the data: URL check works across all JavaScript runtimes.

Comprehensive 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 within limits requests still succeed.

Detection Methods

Dependency and Version Scanning (SCA)

The most immediate and reliable detection method is Software Composition Analysis. The vulnerability range (>= 1.7.0 and < 1.16.0) is tracked across all major vulnerability databases 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 will automatically flag projects with a vulnerable axios version.

Critically, 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 reveals 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 actually 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. This includes 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

Because exploitation manifests as resource exhaustion, defenders can look for anomalous runtime behavior. Corgea's advisory specifically calls out reviewing telemetry for memory and CPU spikes and inspecting outbound traffic for unusually large forwarded payloads on services that processed untrusted bodies or URLs through the fetch adapter. Container orchestrators or APM tools that track per process memory allocation are well positioned 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 indicates that WAF protection rules for the observed attack patterns are available, though these are restricted 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 specific size limit bypass. Publicly reported Axios related IoCs from early 2026 pertain to the separate npm supply chain compromise incident and should not be conflated with CVE-2026-44488.

Affected Systems and Versions

Versions prior to 1.7.0 are not affected because they lack the fetch adapter code entirely.

The vulnerability is specifically 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 expecting 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 track record over the past several years:

Notable recent vulnerabilities include:

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

The March 2026 supply chain compromise stands as 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]) containing a RAT. The malicious packages were available for approximately 3 hours and 19 minutes. The incident exposed governance weaknesses: core contributor DigitalBrainJS lacked the admin permissions to directly revoke the compromised account's access, and the attacker used GitHub admin privileges to unpin and delete an issue filed by a community member reporting the breach.

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

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