CVE-2026-101904 in Axios
Summary
by MITRE • 09/28/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Axios versions ranging from 1.0.0 to 1.20.0 represents a critical security flaw rooted in improper handling of JavaScript object prototypes during the request configuration normalization process. Axios, widely utilized as a promise-based HTTP client for both browser environments and Node.js applications, relies on an interceptor chain mechanism that allows developers to modify requests before they are dispatched. The core technical failure occurs within the dispatchRequest function, which is responsible for normalizing incoming request configurations. Specifically, this function fails to adequately distinguish between own properties of an object and inherited properties from its prototype chain when processing headers. This oversight creates a vector for prototype pollution attacks where malicious actors can manipulate shared state across multiple requests executed in the same process context.
The operational mechanism of this vulnerability involves a combination of prototype manipulation and interceptor behavior. A separate flaw allows attackers to set Object.prototype.headers, effectively injecting default header values into all objects that do not explicitly define their own headers property. When trusted request interceptors return a new ordinary configuration object without an explicit headers property, the subsequent normalization step in dispatchRequest incorrectly resolves these inherited headers from the polluted prototype rather than treating them as absent or undefined. Consequently, any attacker-controlled data injected into Object.prototype.headers becomes part of every outgoing HTTP request that passes through this specific code path. This behavior bypasses standard security expectations where configuration objects are treated as isolated instances with their own distinct properties.
The impact of this vulnerability is severe, particularly regarding authentication and authorization mechanisms. Since the inherited headers include values set by the attacker, sensitive information such as Authorization tokens or API keys can be inadvertently included in requests intended for different targets or contexts. This leads to unauthorized access scenarios where a user's credentials might be sent to malicious endpoints if those endpoints are targeted via other vectors that trigger this specific request flow. Furthermore, it enables potential data leakage and session hijacking attacks by allowing attackers to inject custom headers like Content-Type or X-Request-ID, potentially disrupting backend processing logic or facilitating cross-site request forgery variants depending on the application's security controls.
This issue aligns with CWE-1321: Improperly Controlled Prototype Manipulation in JavaScript, as it involves the exploitation of prototype inheritance to inject malicious properties into objects that should remain clean and isolated. From an ATT&CK perspective, this vulnerability facilitates Initial Access and Credential Access techniques by allowing attackers to manipulate HTTP headers used for authentication. The flaw highlights the dangers of relying on default object behaviors without explicit checks for own property existence in security-sensitive code paths. Developers must recognize that even trusted libraries can harbor such flaws if they do not strictly enforce prototype isolation during configuration merging or normalization processes.
To mitigate this vulnerability, organizations and developers should immediately upgrade Axios to version 1.20.0 or later, where the dispatchRequest function has been patched to correctly handle inherited properties and prevent the resolution of polluted prototypes as valid headers. For applications unable to update immediately due to dependency constraints, implementing a workaround involves manually ensuring that all request configurations explicitly define an empty headers object when no custom headers are required, thereby preventing the lookup from falling back to Object.prototype.headers. Additionally, security teams should audit codebases for similar patterns where objects are merged or normalized without checking for own properties using methods like hasOwnProperty or modern alternatives such as Object.hasOwn. Regular dependency scanning and adherence to secure coding practices that assume prototype pollution is possible in shared contexts will further reduce the risk of exploitation.