Axios CVE-2026-101904

Exploitation is NOT possible against axios alone. It requires ALL of: (1) a separate, pre-existing same-process prototype-pollution vulnerability that can set Object.prototype.headers; (2) the application using trusted request interceptors that return a NEW ordinary configuration object lacking its own headers property, so normalization falls through to the inherited prototype value; and (3) affected axios versions 1.0.0 through 1.19.x. The AT:P (attack requirements) flag in the vendor vector encodes this dependency. The flaw is limited by being inert without the chained proto-pollution primitive, which is the true root cause; axios 1.20.0+ neutralizes the gadget by filtering shared-prototype-inherited config values.

This is a defense-in-depth 'gadget' fix rather than a standalone exploitable flaw. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VC:N/VI:N/VA:N, SC:L/SI:H/SA:N) yields 6.9 (Medium) and, critically, sets AT:P (attack requirements present) - reflecting that exploitation is impossible without a SEPARATE same-process prototype-pollution vulnerability that plants Object.prototype.headers, plus trusted interceptors that return a replacement config lacking an own headers property. There is no EPSS score, no CISA KEV listing, and no public POC. The description confirms the flaw is inert in isolation: axios itself is only the vehicle that resolves the polluted inherited headers during dispatchRequest normalization. My independent read lowers attack complexity to AC:H (3.1) because the required proto-pollution primitive and specific interceptor pattern are non-default and attacker-uncontrollable from axios alone. The 4.0 impact metrics point to subsequent-system integrity (SI:H) - attacker-controlled headers, including authorization-related values, injected into downstream requests - which is fundamentally an integrity/header-injection issue, only secondarily an information-disclosure one (SC:L). Verdict: NOT a standalone priority; real-world risk is contingent on already having a proto-pollution bug in the same process, at which point the proto-pollution itself is the more severe root cause. Treat as hardening; patch during normal dependency maintenance.

In an application already carrying a separate same-process prototype-pollution vulnerability, an attacker sets Object.prototype.headers to attacker-controlled values (e.g. a forged Authorization header). A trusted request interceptor returns a new plain config object without its own headers property, so after the interceptor chain dispatchRequest normalizes and resolves the inherited prototype headers into the outbound request, which downstream processing then honors. No public exploit code exists, and the chain requires an independent proto-pollution primitive to be present.