CVE-2026-42264

What it actually does

Axios versions 1.0.0 through versions before 1.15.2 can read certain HTTP adapter configuration values from inherited object properties instead of only from the request's own configuration. If any other code or dependency in the same JavaScript process first pollutes Object.prototype, axios may unintentionally apply attacker-controlled inherited values for auth, baseURL, socketPath, beforeRedirect, or insecureHTTPParser to outbound HTTP requests. Depending on which property is polluted, this can redirect requests to attacker-controlled destinations, alter authentication behavior, route traffic through local Unix sockets, modify redirect handling, or enable more permissive HTTP parsing. The flaw is best understood as an axios prototype-pollution gadget: it generally requires a separate prototype-pollution primitive to be exploitable, which is why attack complexity is high, but successful exploitation can affect confidentiality and integrity of outbound HTTP traffic.

Why it matters to the business

Applications using vulnerable axios versions may send sensitive outbound requests, credentials, tokens, or internal service calls to unintended destinations if another vulnerability in the same process allows prototype pollution. This can lead to data exposure, unauthorized access to internal services, manipulation of integrations, and compromise of trust between systems. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS activity, but axios is widely used in Node.js and browser-based applications, so exposure can be broad across software supply chains and transitive dependencies.

How an attack unfolds

An attacker first needs a way to pollute Object.prototype in the target JavaScript runtime, commonly through a vulnerable parser, merge utility, deserialization path, query-string handler, or unsafe handling of JSON keys such as __proto__, constructor, or prototype. After establishing that primitive, the attacker sets one or more inherited properties that axios's HTTP adapter reads directly: baseURL, auth, socketPath, beforeRedirect, or insecureHTTPParser. When the application later makes an outbound axios request, axios silently consumes the polluted inherited value as if it had been explicitly configured. A polluted baseURL can cause requests with relative URLs to be sent to an attacker-controlled host; polluted auth can inject or alter credentials; polluted socketPath can route requests to a local Unix socket such as an internal daemon API; polluted beforeRedirect can change behavior during redirects; and polluted insecureHTTPParser can weaken HTTP parsing assumptions. The attacker then collects leaked data, causes the application to call internal resources, or alters request flow without needing to directly modify the application code. No public exploit maturity or KEV exploitation is indicated in the supplied data, so exploitation should be treated as conditional on the presence of a separate prototype-pollution entry point.

How to fix it

Upgrade axios to version 1.15.2 or later everywhere it is used, including direct and transitive dependencies. Regenerate lockfiles after upgrading and redeploy affected applications so the patched package is actually loaded at runtime. If immediate upgrade is not possible, reduce exposure by preventing prototype pollution at application boundaries: reject or sanitize keys such as __proto__, prototype, and constructor in JSON bodies, query parameters, and merge operations; use safe object-merge libraries; create configuration objects with null prototypes where appropriate; and avoid passing untrusted objects into axios configuration. Also consider egress controls that restrict application outbound traffic to expected destinations, because this limits the impact of request redirection or SSRF-like behavior. Review use of axios features involving baseURL, auth, socketPath, redirects, and HTTP parser behavior to ensure security-sensitive requests use explicit, own-property configuration values.

How to confirm the fix worked

Confirm all deployed code paths resolve axios to version 1.15.2 or later. Use package manager tooling such as npm ls axios, yarn why axios, pnpm why axios, software composition analysis, and lockfile review to identify both direct and transitive vulnerable versions. Validate container images, serverless bundles, frontend bundles, and vendored dependencies, not only source repositories. In a safe non-production test, attempt to pollute Object.prototype with an axios-relevant property such as baseURL and verify that patched axios does not apply the inherited property to a request unless it is explicitly present on the request config object. Confirm deployed artifacts were rebuilt after dependency updates and that runtime dependency trees match the fixed versions. Network validation should show outbound axios traffic only to expected destinations after the fix.

Typical attack path

1. Identify an application or service using axios versions 1.0.0 through before 1.15.2.
2. Find a separate prototype-pollution vulnerability in the same JavaScript process, often through unsafe object merge, request body parsing, query parsing, or deserialization.
3. Pollute Object.prototype with one or more axios-relevant properties such as baseURL, auth, socketPath, beforeRedirect, or insecureHTTPParser.
4. Trigger application functionality that performs outbound HTTP requests using axios.
5. Cause axios to inherit the polluted configuration value during request construction.
6. Redirect, modify, or reroute outbound traffic to expose credentials, access internal services, or manipulate integration behavior.
7. Use resulting data exposure or internal access to expand impact within the application or connected services.

How to detect it

This vulnerability does not provide a single reliable host-level indicator because exploitation depends on a separate prototype-pollution vector and manifests as altered outbound HTTP behavior. To check for prior exploitation, correlate application request logs, API gateway logs, outbound proxy logs, DNS logs, firewall egress logs, and APM traces for unexpected outbound destinations from services that use vulnerable axios versions. Look for requests that should have gone to known integration hosts but instead went to new external domains, localhost, 127.0.0.1, ::1, RFC1918 internal addresses, link-local metadata addresses such as 169.254.169.254, or local daemon APIs. Review application logs for suspicious request bodies or query parameters containing __proto__, constructor, prototype, or nested object keys that precede anomalous outbound axios calls. Inspect whether Authorization headers, Basic auth credentials, redirect behavior, or Unix socket routing changed unexpectedly. In Node.js telemetry, investigate errors or traces involving axios requests, redirect callbacks, socketPath use, or HTTP parser behavior that occur after inputs containing prototype-pollution keys. If packet capture or proxy logs are available, compare expected hostnames and paths for normal integration traffic against observed destinations during the suspected window. Since no specific threat actor or public exploit maturity is provided, treat detections as behavioral and context-driven rather than IOC-driven.

What your security team should do

• Prioritize inventory of applications using axios 1.0.0 through before 1.15.2, including transitive dependency paths in Node.js services and bundled client applications.
• Upgrade axios to 1.15.2 or later and redeploy affected services; do not rely solely on source changes without rebuilding lockfiles and runtime artifacts.
• Search for and remediate separate prototype-pollution weaknesses in the same applications, especially unsafe merges, recursive object assignment, query parsing, and JSON handling that allow __proto__, constructor, or prototype keys.
• Apply egress allowlisting for server-side applications so unexpected baseURL or socketPath manipulation cannot freely exfiltrate data or access internal services.
• Review application logs and outbound proxy/DNS telemetry for unexpected axios-originated requests to attacker-controlled domains, localhost, link-local metadata services, internal control-plane endpoints, or Unix-socket-backed APIs.
• Add dependency scanning policies that fail builds on vulnerable axios versions and alert when vulnerable transitive versions are introduced.
• Because this is not currently KEV-listed and has low EPSS, handle as a high-priority dependency remediation for exposed or integration-heavy applications rather than as evidence of active mass exploitation by itself.