CVE-2026-42033

What it actually does

Axios versions prior to 1.15.1 and 0.31.1 can trust inherited properties from Object.prototype when reading certain configuration fields. If another vulnerability or unsafe dependency in the same JavaScript process allows prototype pollution, attacker-controlled properties can be inherited by Axios requests. Depending on which property is polluted, the attacker may alter response transformation logic before application code receives JSON data, or replace/hijack the HTTP transport path used by Axios. This can expose outbound request headers, credentials, tokens, and bodies, and can allow response data integrity manipulation without directly compromising the remote service being called.

Why it matters to the business

Applications using vulnerable Axios versions may make business decisions based on attacker-modified API responses or unknowingly leak sensitive outbound request data such as session tokens, API keys, authorization headers, and request bodies. The issue requires a separate prototype-pollution primitive in the same process, so exploitation is higher complexity, but Axios is widely used in browser and Node.js ecosystems, making dependency exposure common across web applications, back-end services, CLIs, and build tooling. It is not currently listed in CISA KEV and no public exploit maturity was provided, but the confidentiality and integrity impact can be significant where Axios handles authenticated service-to-service or user-facing API traffic.

How an attack unfolds

An attacker first reaches an input path in the application or a co-dependency that can write attacker-controlled keys onto Object.prototype, commonly through unsafe recursive merge, clone, query-string parsing, or JSON object handling. The attacker pollutes a property name that Axios later reads as part of request configuration or response processing. When the application subsequently makes an Axios request, Axios resolves the polluted inherited property as if it were legitimate configuration. In the response-manipulation scenario, attacker-controlled transformation behavior can alter JSON data before application business logic sees it. In the transport-hijack scenario, the polluted configuration can cause Axios to route requests through attacker-controlled transport behavior, exposing request URLs, headers, credentials, and bodies and potentially returning attacker-controlled responses. The attacker does not need to authenticate to Axios itself; the practical prerequisite is achieving prototype pollution elsewhere in the same JavaScript runtime before Axios is invoked.

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. Ensure package-lock.json, yarn.lock, pnpm-lock.yaml, vendored bundles, container images, and downstream packages are rebuilt so the fixed version is actually deployed. Because exploitation requires a separate prototype-pollution source, also audit and update dependencies that perform deep merge, object path assignment, query parsing, YAML/JSON parsing, or configuration merging. Where immediate upgrade is not possible, reduce risk by rejecting dangerous object keys such as __proto__, prototype, and constructor at trust boundaries; using schema validation with additional properties disabled where practical; creating objects with null prototypes for untrusted maps; freezing Object.prototype only after compatibility testing; and avoiding dynamic Axios configuration derived from untrusted input.

How to confirm the fix worked

Confirm the deployed dependency graph resolves Axios to 1.15.1 or later, or 0.31.1 or later for applications pinned to the 0.x branch. Validate with package manager commands such as npm ls axios, yarn why axios, or pnpm why axios, and inspect lockfiles and built artifacts for older bundled copies. Run software composition analysis against source repositories, CI artifacts, and container images. Add regression tests that attempt to pollute Object.prototype with relevant Axios configuration keys and verify Axios does not consume inherited properties. Also test that application input validation rejects __proto__, constructor, and prototype keys in JSON bodies, query strings, form submissions, and configuration files.

Typical attack path

1. Identify an application or package that uses Axios prior to 1.15.1 or 0.31.1.
2. Find an input vector handled by the application or a dependency that is vulnerable to prototype pollution.
3. Submit crafted input containing prototype-pollution keys such as __proto__, constructor.prototype, or nested prototype properties.
4. Pollute an Object.prototype property that Axios reads during request configuration, response transformation, or transport selection.
5. Wait for or trigger the application to make an Axios request in the same process.
6. Intercept or modify Axios response data before application logic consumes it, or hijack the outbound HTTP transport to capture request secrets and influence responses.
7. Use stolen credentials or manipulated business data for follow-on access, fraud, lateral movement, or persistence.

How to detect it

Detection should focus on evidence of prerequisite prototype pollution and anomalous Axios network behavior, because this vulnerability does not produce a unique on-host artifact by itself. Review web access logs, API gateway logs, WAF logs, application request logs, and body/query parameter telemetry for attempts to submit __proto__, constructor.prototype, prototype, or nested object-assignment keys. Correlate those events with application logs showing unexpected Axios request destinations, proxy use, adapter/transport errors, response parsing anomalies, or changes in downstream API response content. In Node.js services, review error logs and telemetry for unusual TypeError or configuration errors around Axios request dispatch, response transformation, adapters, proxies, agents, or transports after suspicious input. Inspect outbound proxy, egress firewall, DNS, and service-mesh logs for Axios-capable services communicating with unfamiliar hosts immediately after prototype-pollution attempts. If exploitation is suspected, capture process memory or runtime diagnostics where feasible and check whether Object.prototype contains unexpected enumerable properties, especially properties related to request configuration, response transformation, proxying, adapters, or transport. Review source and dependency updates for packages known to process untrusted objects unsafely, and treat successful pollution indicators as potential compromise of any Axios-managed credentials used in that process.

• __proto__
• %5F%5Fproto%5F%5F
• constructor.prototype
• constructor[prototype]
• constructor%5Bprototype%5D
• prototype.polluted
• prototype%5Bpolluted%5D
• "__proto__"
• "constructor":{"prototype"
• "prototype":{"polluted"
• Object.prototype.polluted
• axios adapter
• axios transport
• transformResponse
• ERR_BAD_RESPONSE
• ERR_NETWORK

What your security team should do

• Prioritize inventory of all applications, services, serverless functions, containers, and front-end bundles that include Axios versions earlier than 1.15.1 or 0.31.1.
• Upgrade Axios to 1.15.1 or later, or 0.31.1 or later where remaining on the 0.x line is unavoidable.
• Search the dependency graph for known prototype-pollution vulnerabilities, especially in merge, parser, object-path, and configuration libraries, because this Axios issue requires a pollution primitive from another source.
• Review services that use Axios with high-value credentials, authorization headers, service tokens, payment data, or privileged internal API access and patch those first.
• Add centralized input validation or WAF/API-gateway rules to flag or block prototype-pollution payloads containing __proto__, constructor.prototype, and prototype assignment patterns.
• Rotate exposed API keys or service credentials if logs or forensic review suggest prototype-pollution attempts coincided with sensitive Axios traffic.
• Add tests and secure coding guidance requiring hasOwnProperty/Object.hasOwn checks when reading configuration-like objects and forbidding unsafe recursive merges of untrusted input.