CVE-2026-101904: Axios: Header Injection via Inherited headers After Minimal Interceptor

Published Sep 28, 2026
·
Updated

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 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:

js 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:

js 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.

<details> <summary><h3>Original report</h3></summary>

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:

js 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

js 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:

json { "x-poisoned": "yes", "if-none-match": "", "user-agent": "axios/1.17.0" }

References

- https://github.com/axios/axios/security/advisories/GHSA-898c-q2cr-xwhg - https://osv.dev/vulnerability/GHSA-898c-q2cr-xwhg </details> ---

Other sources

Axios is a promise-based HTTP client for the browser and Node.js. From 1.0.0 until 1.20.0, the dispatchRequest function normalizes inherited Object.prototype.headers from a replacement request configuration. A separate same-process prototype-pollution flaw sets Object.prototype.headers, and trusted request interceptors return a new ordinary configuration without an own headers property. After the interceptor chain, dispatchRequest resolves the inherited headers during normalization. Downstream request processing can observe attacker-controlled headers, including authorization-related values. This issue is fixed in version 1.20.0.

— MITRE

Axios: Header Injection via Inherited headers After Minimal Interceptor

— Microsoft

Affected Software

4 affected componentsFixes available
npm/axios>=1.0.0<1.20.0
npm/axios>=1.0.0<1.20.0
1.20.0
IBM Db2 Genius Hub<=1.1.2, 1.1.3, 1.1.4, 1.1.5
IBM Agentics<=1.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/axios to a version that resolves this vulnerability.

    Fixed in 1.20.0
  2. Upgrade

    Upgrade axios to a version that resolves this vulnerability.

    Fixed in 1.20.0
  3. Configuration

    When an interceptor rebuilds and returns a replacement config, preserve config.headers or set an own headers property such as headers: {}; alternatively, mutate and return the existing merged config.

    axios request interceptors own headers property on replacement configuration = {}

Event History

Sep 28, 2026
CVE Published
via MITRE·05:29 PM
Data Sourced
via MITRE·05:29 PM
DescriptionWeakness
Data Sourced
via NVD·06:17 PM
DescriptionSeverityWeakness
Sep 30, 2026
Advisory Published
via GitHub·03:35 PM
Data Sourced
via GitHub·03:35 PM
DescriptionWeaknessAffected Software
Oct 1, 2026
Data Sourced
via Microsoft·08:20 AM
DescriptionSeverityWeakness
Nov 3, 2026
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Frequently Asked Questions

1

Which Axios versions need remediation?

Axios versions from 1.0.0 up to, but not including, 1.20.0 are affected. The issue is fixed in Axios 1.20.0.

2

What conditions are required for exploitation?

An attacker must first be able to trigger a separate prototype-pollution issue in the same process that sets Object.prototype.headers. A trusted request interceptor must also return a new ordinary request configuration that does not have its own headers property.

3

What should teams review to determine exposure?

Review whether the application uses an affected Axios version, has any same-process prototype-pollution path, and uses request interceptors that replace the request configuration without defining an own headers property. Under those conditions, downstream request handling may receive attacker-controlled headers, including authorization-related values.

4

What is the available remediation?

Upgrade Axios to version 1.20.0. The provided information does not identify a separate configuration-only workaround.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203