CVE-2026-67317: High maxBodyLength Bypass in axios Fetch Adapter

CVE-2026-67317 is a high severity (CVSS 7.5) flaw in axios, the JavaScript HTTP client. From version 1.7.0 up to 1.18.0, the fetch adapter does not enforce maxBodyLength on streamed request bodies of unknown length, so upload caps can be bypassed. Upgrade to axios 1.18.0 or later.

What's affected

The record says axios versions 1.7.0 before 1.18.0 are affected. The GitHub advisory (GHSA-jqh4-m9w3-8hp9) lists the same range: 1.7.0 and later, patched in 1.18.0.

The scope is narrow. The advisory says the problem applies when the fetch adapter is in use, which happens in edge runtimes where fetch is selected, and in Node.js or browser code where adapter: "fetch" is chosen explicitly. It also says the HTTP adapter's stream upload path is not affected, so a default Node.js setup that uses the HTTP adapter is outside this issue.

Severity differs between sources. The NVD record scores it 7.5 (High) with a vector that rates availability impact as high. The GitHub advisory labels the same issue Moderate. Both are reported here. Plan around the higher number if you accept untrusted uploads, and treat it as lower priority if you never pass streams to axios.

How to check if you're exposed

npm ls axios
npm why axios

npm ls prints every copy of the package in the tree with its version. npm why shows which dependency pulled each copy in, which matters because a transitive copy is not fixed by bumping your own direct dependency.

Then search your code for the fetch adapter and for stream bodies:

grep -rn "adapter" src | grep -i fetch
grep -rn "maxBodyLength" src

If you never select the fetch adapter, never run in an edge runtime that selects it, and never send a ReadableStream body, you are most likely not exposed in practice. You should still upgrade, since the version range matches.

A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.

What to do now

1. Upgrade axios to 1.18.0 or later, and rebuild any lockfile that pins an older transitive copy.
2. Search for places where you send a ReadableStream as a request body, especially proxy or upload relay code that depends on maxBodyLength.
3. Until you can upgrade, follow the advisory workaround: use the HTTP adapter for untrusted stream uploads in Node.js, or count bytes on the stream in your own code and abort it when it passes your limit.
4. Do not rely on fetch adapter maxBodyLength for unknown-length streams on any version before the fix.
5. Add a size limit at the reverse proxy or gateway as a second layer, so a client library setting is not your only cap.

Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.

Why it matters

The weakness is CWE-770, allocation of resources without limits or throttling. axios offers maxBodyLength as a guard. For a normal body the size is known before sending, so the check is easy. A live stream has no known length, so the fetch adapter had nothing to compare against and the cap never fired.

The result is a limit that looks configured but does not hold. The record describes the impact as uncontrolled network egress or resource exhaustion. Nothing here says data is stolen or code runs. It is a denial of service and cost problem, and it matters most for services that relay user uploads onward. The record does not mark this CVE as known exploited in the wild.

Try it yourself

Knowing which axios copies you ship, and where they come from, is the first step. This demo walks through building that inventory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• https://github.com/axios/axios/security/advisories/GHSA-jqh4-m9w3-8hp9
• Record: NVD entry for CVE-2026-67317 (score 7.5, HIGH)

Last reviewed: 18 October 2026.