A polluted prototype can hijack your axios traffic. Upgrade to 1.18.0.

On August 1, the maintainers of axios disclosed CVE-2026-67320, a prototype pollution weakness in the library's Node.js HTTP adapter. axios is one of the most-installed packages on npm, so this one reaches a lot of backends. The short version: under the right conditions, an attacker who can pollute Object.prototype can make your server route its outbound HTTP requests through a proxy they control. For plaintext http:// calls, that proxy can read the Authorization header, Basic auth credentials, the method, the full URL, the Host header, and the request body, then hand back a response of its choosing. NVD scored it 8.3 (High) on CVSS 4.0.

Here is the mechanism, because the detail matters. axios hardens its merged request config by building it on a null-prototype object, so inherited properties can't leak in. But request interceptors run after that merge, and a very common interceptor pattern, return { ...config } or Object.assign({}, config), quietly converts that hardened object back into an ordinary one with Object.prototype in its chain. The Node adapter then reads config.proxy off that object, walks the prototype chain, and finds whatever an attacker planted at Object.prototype.proxy. The fix in 1.18.0 reads those nested config values through a safe accessor that ignores inherited properties.

One honest caveat: axios by itself doesn't hand an attacker this. They need a separate prototype pollution bug somewhere in your app or your dependency tree to set Object.prototype.proxy in the first place. axios is the amplifier, not the entry point. That is exactly why it's worth taking seriously. Prototype pollution gadgets are common in JavaScript codebases, and this turns a finding a lot of teams write off as theoretical into credential exfiltration.

We see this pattern constantly during our pentesting and security reviews. A client's scanner flags a prototype pollution issue, someone triages it as "no real impact," and it sits in the backlog for a year. Then a bug like this lands and the theoretical becomes a straight line to leaked tokens. Prototype pollution is rarely the whole exploit. It's the primitive that makes the next bug much worse.

The immediate action is boring and you should do it today: upgrade axios to 1.18.0, or 0.33.0 if you're still on the 0.x line. Anything from 1.15.2 up to 1.18.0, or 0.31.1 up to 0.33.0, is affected. Run npm ls axios and it will show you every copy in your tree, including the transitive ones your own code never imported. Those transitive copies are usually the ones that bite you, because nobody is watching them.

Then go a step further than the patch. From our PHP and Docker work building cloud-native backends, the teams that handle these disclosures calmly are the ones that already treat outbound traffic as something to control, not just inbound. A few things that pay off here:

• Send server-to-server calls over https://, always. This bug leaks nothing over properly validated TLS. The plaintext http:// internal call between two services is the one that burns you.
• Lock down egress. If a service only needs to reach three known hosts, an egress allowlist or a proxy you actually run means a hijacked config.proxy has nowhere useful to go.
• Keep secrets out of URLs and shorten the lifetime of anything you send in Authorization on internal hops. Short-lived tokens limit the damage when something does leak.

There is a mobile angle too, and it's easy to miss. In our native iOS and Android projects the app itself isn't running axios, but the backend-for-frontend or API gateway sitting behind it very often is. A leaked upstream token there can quietly compromise every mobile client downstream, and you won't see it in the app's own logs. When we review a mobile system we trace the token all the way back through the backend, not just to the first hop.

The lesson underneath the CVE is the one worth keeping. Your dependency tree is attack surface, and "we don't use that feature" is not the same as "that code can't run." axios has proxy support you may never configure, and the vulnerability lived there anyway. Knowing what's actually installed, and being able to patch it in an afternoon, is a capability you build before you need it, not during an incident.

If you're not sure what's sitting in your dependency tree or how outbound traffic leaves your services, let's talk.