CVE-2026-42041

What it actually does

Axios versions prior to 1.15.1 and 0.31.1 contain a prototype-pollution gadget in configuration merging for the validateStatus option. Because this option is merged using logic that relies on JavaScript's in operator, inherited properties on Object.prototype can be treated as if they were explicitly supplied in an Axios request configuration. If an attacker can first pollute Object.prototype.validateStatus with a function that returns true, Axios will treat all HTTP response status codes, including 401, 403, 404, and 500, as successful responses. The flaw does not by itself create prototype pollution; it amplifies an existing or reachable prototype-pollution primitive into authorization, authentication-flow, and error-handling bypasses in applications that rely on Axios response failures to enforce security decisions.

Why it matters to the business

Applications using affected Axios versions may silently ignore failed upstream authorization or authentication checks, causing access-denied and server-error responses to be processed as successful results. This can lead to improper access decisions, incorrect workflow completion, failed fraud or policy checks, data integrity issues, and reduced visibility because expected error-handling paths may not run. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but Axios is widely used across browser and Node.js applications, so exposure can be broad in organizations with many JavaScript dependencies.

How an attack unfolds

An attacker first needs a way to introduce prototype pollution into the same JavaScript execution context where Axios requests are made, such as through unsafe parsing or merging of attacker-controlled JSON, query parameters, form fields, or configuration objects. The attacker pollutes Object.prototype by adding a validateStatus property whose value is a function that always returns true. When vulnerable Axios later builds a request configuration without its own validateStatus value, the merge logic checks the prototype chain and accepts the polluted inherited property. Subsequent HTTP calls no longer reject non-2xx responses. Application code that expects Axios to throw on 401, 403, or 500 may continue along a success path, potentially treating denied authentication, failed authorization, or failed upstream validation as approved.

How to fix it

Upgrade Axios to a fixed release: use Axios 1.15.1 or later for the 1.x line, or Axios 0.31.1 or later for the 0.x line. Regenerate lockfiles and redeploy all browser bundles, server-side Node.js services, serverless functions, CLI tools, and transitive dependency consumers that package vulnerable Axios versions. Where immediate upgrade is not possible, explicitly set a safe own-property validateStatus function on Axios instances and request configurations, for example accepting only the intended success range, and remove or block any code paths that allow prototype pollution through __proto__, prototype, or constructor keys. Harden object merging and parsing routines, use schema validation for untrusted input, and consider creating null-prototype objects for untrusted dictionaries.

How to confirm the fix worked

Confirm dependency resolution with package tooling such as npm ls axios, yarn why axios, pnpm why axios, or software composition analysis output, and verify that no deployed artifact contains Axios versions earlier than 1.15.1 or 0.31.1. Inspect bundled JavaScript where applicable because frontend builds may contain vendored Axios copies not visible at runtime. Add a regression test that intentionally sets Object.prototype.validateStatus in an isolated test process and verifies that Axios still rejects 401, 403, and 500 responses after the upgrade. Also test key application flows to ensure denied upstream responses continue to trigger the expected failure and error-handling paths.

Typical attack path

1. Identify an application or client-side workflow that uses Axios before version 1.15.1 or 0.31.1.
2. Find a reachable prototype-pollution source in the same JavaScript runtime, such as unsafe deep merge, object assignment, or parsing of __proto__, constructor, or prototype keys.
3. Submit crafted input that sets Object.prototype.validateStatus to a function returning true.
4. Trigger an Axios request that relies on default validateStatus behavior and does not explicitly define a safe local validateStatus function.
5. Cause the upstream service to return an error status such as 401, 403, or 500.
6. Abuse application logic that incorrectly treats the error response as a successful response.

How to detect it

This issue is difficult to detect from network traffic alone because it changes client-side or server-side application control flow rather than producing a unique request signature. Review application logs for cases where upstream services returned 401, 403, 404, or 500 responses but the calling application recorded a successful business action, authorization decision, or workflow completion. In Node.js services, correlate outbound HTTP client logs, reverse-proxy logs, API gateway logs, and application audit logs for mismatched status handling. Search source code, request logs, WAF logs, and telemetry for prototype-pollution payloads targeting validateStatus or common prototype keys. In browser applications, review client error telemetry and session replay metadata, if available, for unexpected successful UI transitions after failed API responses. During forensic review, look for evidence of Object.prototype.validateStatus being assigned, suspicious use of __proto__, constructor.prototype, or prototype keys in user-controlled payloads, and anomalous disappearance of Axios error-handling events.

• Object.prototype.validateStatus
• __proto__.validateStatus
• __proto__[validateStatus]
• constructor.prototype.validateStatus
• prototype.validateStatus
• "validateStatus":"() => true"
• "validateStatus":"()=>true"
• validateStatus: () => true
• validateStatus:function(){return true}
• "__proto__":{"validateStatus"
• "constructor":{"prototype":{"validateStatus"
• Cannot read properties of undefined reading 'validateStatus'

What your security team should do

• Inventory all direct and transitive Axios usage across repositories, deployed services, browser bundles, serverless packages, and container images.
• Prioritize upgrades for applications where Axios responses influence authentication, authorization, payment, entitlement, workflow approval, or security-control decisions.
• Upgrade to Axios 1.15.1 or later, or 0.31.1 or later where the legacy 0.x line must be retained.
• Search codebases for unsafe merge or parser patterns that permit __proto__, prototype, or constructor keys, because this vulnerability requires a prototype-pollution source to become exploitable.
• Add tests that ensure 401, 403, and 5xx responses are handled as failures in security-sensitive Axios workflows.
• Temporarily add explicit validateStatus functions to critical Axios clients if patch rollout cannot be completed immediately.
• Monitor application logs for unusual success-path execution after upstream 401, 403, or 500 responses.