CVE-2026-67319

If you're using axios in a Node.js environment, check your version immediately: this vulnerability affects versions prior to 0.33.0 and 1.18.0. The core issue is that axios applies prototype-pollution hardening only at the top level of its config object using null-prototype objects, but nested config objects (such as values within `auth`, `headers`, or any developer-provided config sub-objects) are cloned into ordinary objects that inherit from `Object.prototype`. If your environment already has prototype pollution from any source — and in Node.js this is disturbingly common from polyfills, middleware, or other libraries — axios will propagate that pollution into its internal config merging logic, potentially allowing an attacker to override settings they should not control. The deceptive part: axios's use of null-prototype objects at the top level is a deliberate security measure, not an accident. This means developers who understand the pattern may reasonably assume the library is hardened against prototype pollution throughout. It isn't. The trust boundary is invisible — top-level config gets protection, nested config gets naive cloning, and there's no runtime signal that these paths differ. What to check: audit your dependency tree for any code that pollutes `Object.prototype` (search for `__proto__` assignments, `Object.prototype` modifications, or use a tool like `prototype-scanner`). Audit any places where your application passes objects into axios config that could be influenced by request input. Consider wrapping axios config creation with `Object.create(null)` to ensure the entire chain uses null-prototype objects, or freeze your config objects before passing them to axios. Upgrading is the definitive fix, but given the age of the affected versions, ensure you're not running axios in a context where other library vulnerabilities could have already polluted the prototype chain.

Reviewed through automated stages and approved by a human before publication.