CVE-2026-42034

What it actually does

Axios versions prior to 1.15.1 and 0.31.1 fail to enforce the configured maxBodyLength limit for streamed request bodies when maxRedirects is set to 0, which causes Axios to use the native Node.js http/https transport path. As a result, applications that rely on Axios to cap outbound streamed upload size may transmit the entire stream despite a strict body-size limit. The primary impact is availability/resource exhaustion through excessive outbound data transfer, memory/CPU pressure in surrounding application code, saturated network links, or overload of upstream services that receive unexpectedly large uploads.

Why it matters to the business

Applications that use Axios as part of upload forwarding, API gateway, proxy, webhook, file-ingestion, or integration workflows may be exposed to unexpected high-volume outbound transfers. This can increase cloud egress costs, degrade service performance, exhaust worker capacity, or disrupt dependent internal and third-party services. The issue is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, but it is easy to trigger in affected application patterns and should be remediated during normal dependency update cycles, with higher priority for internet-facing services that accept user-controlled streamed input.

How an attack unfolds

An attacker first identifies an application endpoint that accepts or generates a streamed request body and then forwards that stream using Axios with maxRedirects set to 0 and maxBodyLength configured as a safety limit. The attacker submits or causes the application to process an oversized stream, such as a very large upload or long-lived request body. Because the vulnerable Axios transport path does not enforce maxBodyLength, the application continues sending the full stream to the destination instead of aborting at the configured limit. Repeated requests can consume outbound bandwidth, keep application workers busy, increase egress charges, or overload the receiving service. Exploitation does not generally provide code execution or data theft by itself; the practical risk depends on whether attackers can influence streamed request bodies handled by the affected Axios call path.

How to fix it

Upgrade Axios to a fixed release: use axios 1.15.1 or later on the 1.x line, or axios 0.31.1 or later on the 0.x line. Ensure package-lock.json, yarn.lock, pnpm-lock.yaml, or other lockfiles resolve to the fixed version and rebuild/redeploy affected services. Where immediate upgrade is not possible, avoid relying solely on Axios maxBodyLength for streamed input when maxRedirects is 0; enforce request-size limits before creating the stream, at the reverse proxy/load balancer, at upload middleware, and in application logic that counts bytes as the stream is read. Apply upstream service-side size limits as a secondary control. Rate-limit upload/proxy endpoints, set request timeouts, cap concurrent uploads, and monitor outbound transfer volume until patched.

How to confirm the fix worked

Confirm that dependency resolution shows axios 1.15.1 or later, or 0.31.1 or later, in all deployed artifacts and containers. Inspect lockfiles and software composition analysis results rather than only package.json version ranges. Add or run a regression test that performs a streamed upload larger than the configured maxBodyLength with maxRedirects set to 0 and verifies that Axios aborts instead of transmitting the full body. Validate edge controls by confirming reverse proxies, upload handlers, API gateways, and upstream services reject bodies above intended limits. In production, compare expected versus actual outbound byte counts for upload/proxy code paths after deployment to ensure oversized streams are no longer transmitted.

Typical attack path

1. Find an application feature that accepts, proxies, relays, or generates streamed HTTP request bodies using Axios.
2. Determine or infer that the forwarding path disables redirects by setting maxRedirects to 0.
3. Send an oversized or long-running streamed payload to the application-controlled entry point.
4. Cause the application to forward the payload with Axios while expecting maxBodyLength to stop transmission.
5. Abuse the bypass so the full oversized stream is transmitted anyway.
6. Repeat or parallelize requests to consume bandwidth, worker slots, upstream capacity, or cloud egress budget.

How to detect it

There are no universal exploitation indicators for this library flaw because abuse appears as oversized or long-running application-specific HTTP traffic. To determine whether it was already exploited, review application access logs, reverse proxy logs, API gateway logs, upload service logs, outbound HTTP client telemetry, cloud egress metrics, and upstream service logs for unusually large request bodies or sustained streams that should have been blocked by configured body limits. Focus on time periods when affected Axios versions were deployed and on endpoints that accept uploads, proxy requests, or relay streamed content. Look for repeated requests from the same source, long request durations, high outbound-to-inbound byte ratios, spikes in network egress, upstream 413/408/429/5xx responses, worker exhaustion, connection timeouts, and application messages involving maxBodyLength, stream aborts, or upload size enforcement failures. Correlate suspicious requests with dependency deployment timelines and with code paths using maxRedirects: 0.

What your security team should do

• Inventory applications and services that include Axios, especially Node.js services handling uploads, proxies, API forwarding, webhook relays, or streamed request bodies.
• Prioritize remediation for internet-facing services where untrusted users can influence streamed request bodies sent through Axios.
• Upgrade to axios 1.15.1 or later, or 0.31.1 or later, and verify lockfile and runtime dependency resolution.
• Search code for Axios calls that combine streamed request bodies, maxBodyLength, and maxRedirects: 0, and add explicit byte-counting safeguards where needed.
• Enforce independent request-size limits at ingress proxies, application middleware, and upstream receiving services rather than relying on one client-library limit.
• Add tests for oversized streamed uploads to prevent future regression.
• Monitor outbound bandwidth, long-lived upload requests, HTTP 413/408/499/502 patterns, and upstream service saturation for signs of abuse.