CVE-2026-44488

What it actually does

Axios versions 1.7.0 through 1.15.x fail to enforce configured maxContentLength and maxBodyLength limits when the fetch adapter is used. As a result, applications may download, upload, or forward payloads larger than the application explicitly intended to allow. In server-side Node.js usage, this can consume excessive memory, CPU, bandwidth, or disk-backed buffering resources and cause process instability or denial of service. The flaw affects applications that explicitly configure adapter: 'fetch' or run in environments where Axios resolves to the fetch adapter. It does not directly provide code execution, privilege escalation, or data disclosure, but it can undermine application-level resource controls.

Why it matters to the business

A remote attacker or malicious upstream service can cause an affected application to process unexpectedly large HTTP bodies, potentially leading to slowdowns, crashes, increased infrastructure costs, failed transactions, degraded user experience, or outages. The risk is highest for internet-facing services, API gateways, server-side rendering applications, file-processing workflows, proxy/forwarder patterns, and services that rely on Axios size limits as their primary protection against large payloads. Although this issue is not listed in CISA KEV and has low current EPSS, it has a high availability impact and should be prioritized where Axios is used in request forwarding or untrusted URL-fetching paths.

How an attack unfolds

An attacker first identifies an application endpoint or workflow that causes the server to make an Axios request using the fetch adapter. The attacker then influences either the destination URL, the upstream response, or the request body being forwarded. If the application relies on maxContentLength or maxBodyLength to stop oversized traffic, the vulnerable Axios versions do not enforce those limits under the fetch adapter. The attacker can return a very large response from a controlled or compromised server, provide a large data: URL where accepted, or submit a large body that the application forwards through Axios. The application consumes resources while reading, buffering, sending, or processing the oversized content until latency spikes, memory pressure increases, the process crashes, or service availability is degraded.

How to fix it

Upgrade Axios to a fixed version: 1.16.0 or later for the 1.x line, or 0.32.0 or later where using the 0.x line. Ensure all direct and transitive Axios dependencies are updated through the package lockfile. If immediate upgrade is not possible, avoid using the fetch adapter for untrusted traffic, enforce request and response size limits outside Axios, and apply limits at reverse proxies, API gateways, application middleware, and upstream fetch handlers. For server-side applications, reject untrusted data: URLs unless explicitly required, validate allowed URL schemes and destinations, set strict timeouts, cap streaming reads independently, and avoid buffering entire responses in memory. Treat maxContentLength and maxBodyLength in affected versions as unreliable when the fetch adapter is active.

How to confirm the fix worked

Confirm that installed Axios versions are not in the vulnerable range 1.7.0 through 1.15.x. Use package-manager inspection commands such as npm ls axios, yarn why axios, pnpm why axios, or software composition analysis tooling to identify all resolved versions. Review package-lock.json, yarn.lock, pnpm-lock.yaml, and container build artifacts for vulnerable Axios versions. Validate that applications using Axios with adapter: 'fetch' or fetch-capable runtimes have been rebuilt and redeployed after dependency updates. Where safe, run an integration test against a controlled endpoint that returns a body larger than the configured maxContentLength and verify the request is blocked or fails before excessive memory or bandwidth is consumed. Also test outbound forwarding paths to confirm maxBodyLength or equivalent application-side limits are enforced.

Typical attack path

1. Find an application feature that performs outbound HTTP requests using Axios, such as URL import, webhook delivery, proxying, server-side rendering, API aggregation, or file retrieval.
2. Determine whether the feature accepts attacker-controlled URLs, request bodies, or upstream services that can return arbitrary response sizes.
3. Trigger an Axios request that uses the fetch adapter in an affected Axios version from 1.7.0 through 1.15.x.
4. Serve or submit a payload larger than the configured maxContentLength or maxBodyLength boundary.
5. Cause the application to read, forward, buffer, or process the oversized body despite the configured limit.
6. Repeat or parallelize requests to exhaust memory, CPU, network bandwidth, worker threads, or container limits, resulting in degraded availability or crashes.

How to detect it

Look for evidence of resource-exhaustion attempts against features that make outbound Axios requests or forward request bodies. Relevant sources include application logs, reverse proxy and API gateway logs, outbound proxy logs, egress firewall logs, APM traces, container and orchestration events, Node.js process logs, memory/CPU telemetry, crash reports, and dependency inventory records. Investigate unusual spikes in response sizes, request body sizes, outbound bandwidth, long request durations, HTTP 502/503/504 responses, process restarts, out-of-memory kills, heap allocation failures, or repeated calls to attacker-controlled URLs. Correlate these events with application code paths using Axios fetch adapter, user-supplied URLs, data: URLs, webhook forwarding, file import, or proxy behavior. Since no public exploit-specific payload is indicated, detection should focus on behavioral indicators: oversized bodies that exceeded expected business limits, repeated retries, high memory pressure during outbound HTTP calls, and crashes temporally associated with large upstream responses or forwarded payloads.

• axios@1.7.0
• axios@1.8.0
• axios@1.9.0
• axios@1.10.0
• axios@1.11.0
• axios@1.12.0
• axios@1.13.0
• axios@1.14.0
• axios@1.15.0
• adapter: 'fetch'
• adapter: "fetch"
• maxContentLength
• maxBodyLength
• data:
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• OOMKilled
• OutOfMemoryError
• Request body larger than maxBodyLength limit
• maxContentLength size of

What your security team should do

• Inventory all applications and services that include Axios, including transitive dependencies and bundled frontend/server-side JavaScript artifacts.
• Prioritize upgrades for server-side Node.js services, internet-facing applications, proxy/forwarder components, URL-fetching features, webhook systems, and any code using adapter: 'fetch'.
• Upgrade Axios to 1.16.0 or later, or 0.32.0 or later if pinned to the 0.x branch, and regenerate lockfiles and container images.
• Add defense-in-depth body size controls at ingress proxies, API gateways, application middleware, and streaming read logic rather than relying solely on Axios limits.
• Search code for adapter: 'fetch', maxContentLength, maxBodyLength, data: URL handling, and user-controlled outbound request patterns to identify high-risk call sites.
• Monitor application memory, process restarts, HTTP 5xx spikes, long-running outbound requests, and unusually large request or response sizes for signs of attempted exploitation.
• If exploitation is suspected, preserve application logs, reverse proxy logs, process metrics, crash dumps, and outbound HTTP telemetry before rotating or redeploying affected services.