Prototype pollution turns axios into a request hijacking gadget

TL;DR - axios >= 1.0.0, < 1.15.2 reads five HTTP config properties from Object.prototype without hasOwnProperty guards. If anything else in the process pollutes that prototype, axios silently inherits attacker-controlled values on every outbound request - redirecting calls, injecting credentials, or routing traffic to internal Unix sockets.

What happened

axios is the dominant JavaScript HTTP client for Node.js backends and build tooling. CVE-2026-42264 documents five property reads in its Node HTTP adapter that lack hasOwnProperty guards: auth, baseURL, socketPath, beforeRedirect, and insecureHTTPParser.

None of these reads verify that the value actually belongs to the request config object. If a separate dependency in the same process has polluted Object.prototype, axios inherits those values silently on every request it makes.

That transforms prototype pollution - often dismissed as an abstract data-integrity issue - into a concrete network threat:

• Credential injection: pollute config.auth to force an Authorization header onto outbound requests
• Request redirection: pollute config.baseURL to reroute relative-URL calls to an attacker-controlled host
• Internal socket access: pollute config.socketPath to send requests to internal Unix sockets such as the Docker daemon
• Redirect callback hijacking: pollute config.beforeRedirect to execute attacker-supplied code during HTTP redirects
• Parser weakening: pollute config.insecureHTTPParser to relax HTTP response parsing

axios is a dependency in a huge number of JavaScript backends and CLIs, and prototype pollution is a persistent supply-chain vulnerability class. A single vulnerable transitive dependency that pollutes Object.prototype is all it takes for axios to quietly redirect cross-service calls, inject credentials, or expose internal sockets. For a deeper look at how this class of bug works, see our prototype pollution research hub.

Who is impacted

• Any Node.js process using axios versions >= 1.0.0, < 1.15.2.
• Highest risk: services where untrusted code or a vulnerable transitive dependency can mutate Object.prototype, and where axios makes security-sensitive calls - auth flows, cloud metadata services, internal control planes.
• Applications that use relative URLs with a configured baseURL are particularly exposed: polluting baseURL redirects all of those calls.

What to do now

• Upgrade to axios 1.15.2 or later. The vendor is explicit:

  "This issue has been patched in version 1.15.2."

• Inventory axios across every repo and deployed artefact: lockfiles, bundled frontend assets, container images. Flag anything running >= 1.0.0, < 1.15.2.
• Treat this as a dependency interaction risk, not a standalone exploit:
  • map your dependency graph for known prototype pollution sources
  • prioritise patching for services that hold credentials, call internal admin APIs, or can reach Unix sockets
• Add a targeted regression test in high-risk services: set Object.prototype.baseURL and Object.prototype.auth in a test harness, then assert axios does not inherit those values once patched.
• If you suspect abuse, review outbound request logs for unexpected destination hosts - particularly where code uses relative URLs - and rotate any credentials that may have been sent via injected Authorization headers.

For broader guidance on reducing dependency-driven exposure, see the secure dependency management guide.