May 5, 2026·5 min read·75 visits
A flaw in the Axios configuration merging process allows a polluted Object prototype to overwrite the `validateStatus` function. This causes the client to treat 4xx and 5xx error responses as successful, potentially bypassing authentication and error-handling checks.
Axios versions prior to 1.15.1 and 0.31.1 contain a prototype pollution gadget in the configuration merging logic. This vulnerability allows an attacker to bypass authentication mechanisms by leveraging a separate prototype pollution flaw to manipulate the HTTP response validation process.
Axios is a widely adopted promise-based HTTP client for Node.js and the browser. The library employs a configuration merging system to combine global defaults with per-request configuration objects. This mechanism processes properties like headers, base URLs, and response validation functions.
The vulnerability exists within the lib/core/mergeConfig.js module, specifically affecting how certain direct configuration keys are merged. Axios assigned the validateStatus property to a merging strategy that utilized the JavaScript in operator. This operator inherently traverses the object prototype chain during property existence checks.
Because the in operator evaluates properties on the prototype, Axios acts as a prototype pollution gadget. If an attacker pollutes the global Object.prototype via an independent vulnerability, Axios will adopt the polluted properties during configuration merging. This transforms a generic prototype pollution flaw into a specific application logic bypass.
The root cause of CVE-2026-42041 is the insecure implementation of the mergeDirectKeys strategy within the Axios configuration merging engine. Axios utilizes distinct strategies to handle different types of configuration data. The validateStatus property dictates whether an HTTP response is treated as a success or failure, and it is processed using mergeDirectKeys.
The mergeDirectKeys function originally relied on the JavaScript in operator to determine if a property was supplied in the user's configuration object. The in operator returns true if a property exists directly on the object or anywhere within its prototype chain. This design choice introduced a severe side effect when the global prototype is modified.
When prop in config2 is evaluated, the JavaScript engine checks config2 for the validateStatus property. If the property is absent from config2, the engine inspects Object.prototype. If an attacker has polluted Object.prototype.validateStatus, the in operator returns true, and Axios assigns the malicious function as the active response validator.
The vulnerability manifests in the mergeDirectKeys function located in lib/core/mergeConfig.js. The original code evaluated property existence using the in operator, which exposed the logic to prototype chain pollution.
// Vulnerable Implementation (lib/core/mergeConfig.js)
function mergeDirectKeys(config1, config2) {
// ...
if (prop in config2) { // Traverses the prototype chain
return getMergedValue(config1[prop], config2[prop]);
}
// ...
}The patched implementation replaces the in operator with Object.prototype.hasOwnProperty.call(). This method strictly checks for properties defined directly on the object, ignoring properties inherited through the prototype chain.
// Patched Implementation (lib/core/mergeConfig.js)
function mergeDirectKeys(config1, config2) {
// ...
if (Object.prototype.hasOwnProperty.call(config2, prop)) { // Ignores prototype
return getMergedValue(config1[prop], config2[prop]);
}
// ...
}This fix is complete for the mergeDirectKeys strategy. It effectively neutralizes the specific gadget chain involving validateStatus. Security researchers should note that other JavaScript libraries employing the in operator for configuration merging remain susceptible to similar gadget behavior.
Exploitation requires a pre-existing prototype pollution vulnerability within the target application or its dependencies. The attacker first identifies an entry point, such as a vulnerable deep-merge function or JSON parser, to pollute the global prototype.
The attacker injects a payload that assigns a permissive function to the validateStatus property on Object.prototype. A standard payload sets this property to a function that always returns true, such as Object.prototype.validateStatus = () => true;. This function instructs Axios to accept any HTTP status code as a successful response.
Axios relies on lib/core/settle.js to process responses. The settle module executes the validateStatus function to determine if the Promise should be resolved or rejected. With the polluted function active, settle.js resolves the Promise regardless of the actual server response code.
// lib/core/settle.js execution flow
if (!validateStatus || validateStatus(response.status)) {
resolve(response); // Attacker payload forces this branch to execute
} else {
reject(new AxiosError(...));
}The CVSS v3.1 base score for this vulnerability is 4.8 (Medium), reflecting the high attack complexity. The vulnerability cannot be exploited in isolation; it functions purely as an amplifier for an existing prototype pollution flaw. Despite the medium score, the practical impact on application security can be critical.
Applications frequently use Axios interceptors to enforce authentication and authorization controls. A common pattern involves catching 401 Unauthorized or 403 Forbidden responses to trigger a logout process or token refresh. The prototype pollution gadget bypasses this logic entirely by masking the error response.
When a 401 response is silently converted into a resolved Promise, the application processes the empty or error-formatted response body as legitimate data. This leads to undefined application states, logic errors, or unauthorized access to restricted client-side views. The vulnerability severely compromises the integrity of the client-side state machine.
The primary remediation strategy is upgrading Axios to a patched version. Developers must update their dependencies to Axios version 1.15.1 or 0.31.1. Upgrading removes the insecure in operator from the configuration merging logic.
If immediate patching is not feasible, developers can implement a functional workaround. By explicitly defining a validateStatus function at the global Axios instance level, the application shadows the prototype chain. This prevents the JavaScript engine from traversing up to the polluted Object.prototype.
A secondary defense-in-depth measure involves auditing the application and its dependency tree for primary prototype pollution vulnerabilities. Addressing the root cause of the prototype pollution eliminates the prerequisite for this gadget. Development teams should employ dependency scanning tools and enforce strict input validation on all functions that recursively process object properties.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Axios Axios | < 0.31.1 | 0.31.1 |
Axios Axios | >= 1.0.0, < 1.15.1 | 1.15.1 |
| Attribute | Detail |
|---|---|
| Vulnerability Class | Prototype Pollution Gadget (CWE-1321) |
| Attack Vector | Network-based (Requires prior pollution) |
| CVSS v3.1 Score | 4.8 (Medium) |
| EPSS Score | 0.00088 (24.91%) |
| Primary Impact | Authentication Bypass / Logic Flaw |
| Exploit Status | Proof of Concept available |
Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
A polynomial-time Regular Expression Denial of Service (ReDoS) vulnerability in Soup Sieve versions prior to 2.9 allows remote unauthenticated attackers to cause CPU exhaustion and thread-pool denial of service. The vulnerability resides in the trailing whitespace and comment preprocessing step of the CSS parser. An attacker can trigger quadratic backtracking by submitting a crafted CSS selector string containing a long run of internal spaces or comments terminated by a non-matching token. This blocks the Python Global Interpreter Lock (GIL) and halts worker threads.
A regular expression denial of service (ReDoS) vulnerability in Soup Sieve prior to version 2.9 allows remote attackers to cause CPU exhaustion and service disruption. The issue lies within the definition of the IDENTIFIER and VALUE selector sub-patterns in the CSS parser component, which uses overlapping adjacent quantified groups. When parsing long, crafted, or unclosed CSS selectors, backtracking-based regular expression engines experience quadratic performance degradation. User-controlled selectors can reach this path through soupsieve.compile(), soupsieve.select(), or BeautifulSoup.select(), while applications using only hard-coded selectors are unaffected.
A protocol-level validation bypass in CoreDNS versions prior to 1.14.7 allows unauthenticated remote attackers to proxy unauthorized DNS UPDATE messages (Opcode 5) using modern alternative transport layers such as DoH, DoH3, DoQ, and gRPC. If upstream authoritative servers trust the CoreDNS server's source IP and do not enforce TSIG authentication, attackers can inject, alter, or delete DNS zone records, leading to potential zone takeover or traffic redirection.
A path traversal vulnerability exists in Grav CMS versions prior to 2.0.16. The flaw occurs within the file validation mechanisms of the MediaUploadTrait, enabling authenticated users with media management privileges to bypass sandbox limitations. This allows the deletion of arbitrary files on the filesystem, which can result in denial of service or remote code execution.
An unauthenticated directory traversal vulnerability exists in Grav CMS prior to version 2.0.15. Due to an insecure string-based containment check (str_starts_with) in the pre-boot static asset server, attackers can read files in sibling directories sharing a prefix with the configured asset path when plugin-asset-map.php is enabled.
CVE-2026-75828 is a critical stored cross-site scripting (XSS) vulnerability in the getgrav Grav CMS before version 2.0.15. The vulnerability resides in the detectXss() security filter mechanism, where parser-differential mismatches between the regular-expression-based server-side validation and browser HTML5 tokenization allow authenticated editors to bypass event-handler detection and inject arbitrary JavaScript execution vectors.