CVE-2026-44490

What it actually does

Axios versions prior to 0.32.0 and prior to 1.16.0 contain read-side prototype-pollution gadgets. Axios does not itself create the pollution; exploitation requires another dependency or application code in the same JavaScript process to pollute Object.prototype first. Once polluted, axios may incorrectly inherit attacker-controlled values while merging request configuration and headers. One gadget can cause polluted object properties to be copied into outbound HTTP headers, creating an integrity risk where unintended headers are sent to downstream services. A second gadget can cause Object.defineProperty to read inherited get or set descriptor properties, producing synchronous TypeError exceptions on axios requests and creating an availability impact for code paths that depend on axios.

Why it matters to the business

Applications using vulnerable axios versions can unintentionally send attacker-controlled headers to external or internal services, which may affect authentication flows, routing, tracing, caching, or business logic in downstream systems. In affected request paths, exploitation can also break outbound HTTP calls and cause service errors or partial outages. The practical likelihood is lower than many remotely exploitable flaws because an attacker must first trigger prototype pollution through another dependency or application path in the same process; EPSS is low, it is not in CISA KEV, and no public exploit maturity is reported. However, axios is widely used in Node.js and browser applications, so exposure can be broad across dependency trees.

How an attack unfolds

An attacker first identifies an application path that accepts attacker-controlled structured input and passes it to a vulnerable merge, clone, or object-construction routine capable of polluting Object.prototype, such as an affected lodash merge pattern or similar dependency flaw. The attacker submits crafted input that adds properties to Object.prototype. After that pollution exists in the same JavaScript process, application code makes an axios request. During axios header or configuration merging, vulnerable versions read inherited properties from Object.prototype instead of limiting processing to own safe properties. In the header-merging gadget, attacker-controlled inherited bucket values can be copied into the request headers and sent over the network. In the mergeConfig gadget, inherited get or set properties on the property descriptor can cause Object.defineProperty to throw a TypeError, making axios requests fail synchronously. The attacker’s outcome depends on the polluted properties and the application’s request flow: unintended outbound headers, request tampering, broken integrations, or denial of service for functions that depend on axios.

How to fix it

Upgrade axios to a fixed release: use axios 0.32.0 or later on the 0.x line, or axios 1.16.0 or later on the 1.x line. Because vulnerable axios may be present transitively, inspect lockfiles and software composition analysis results for nested copies and force dependency resolution where appropriate. Also remediate the upstream prototype-pollution source: update vulnerable merge/clone/parsing libraries, avoid unsafe deep merge of attacker-controlled objects, block keys such as __proto__, prototype, and constructor where relevant, and prefer null-prototype objects or safe schema validation for untrusted input. As defense in depth, avoid relying on inherited properties during configuration/header construction, sanitize outbound headers, and add tests ensuring Object.prototype pollution does not alter axios behavior.

How to confirm the fix worked

Confirm that all runtime dependency trees resolve axios to 0.32.0 or later, or 1.16.0 or later, including transitive packages in package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, container images, and deployed bundles. Run npm ls axios, yarn why axios, or pnpm why axios as applicable. Rebuild and redeploy artifacts after lockfile updates rather than only changing package manifests. Add a regression test that deliberately pollutes Object.prototype in an isolated test process, performs an axios request, and verifies that no inherited properties are copied into headers and no TypeError is thrown from axios mergeConfig or utils merge logic. For production exposure review, search deployed artifacts for vulnerable axios package versions and verify that SCA tooling no longer reports this issue.

Typical attack path

1. Find an application using axios before 0.32.0 or before 1.16.0 in a Node.js or browser JavaScript dependency tree.
2. Identify an upstream prototype-pollution primitive in the same process, such as unsafe recursive merge behavior in another dependency or application code.
3. Submit crafted input that pollutes Object.prototype with properties relevant to axios header/configuration handling, or with get/set values that disrupt descriptor creation.
4. Trigger an application feature that performs an axios request after the pollution has occurred.
5. Observe that axios either sends unintended inherited values as outbound HTTP headers or throws synchronous TypeError exceptions that disrupt request handling.
6. Use the resulting behavior to influence downstream service behavior, leak trust assumptions through injected headers, or cause repeated request failures.

How to detect it

To determine whether this was already exploited, focus on evidence of the prerequisite prototype pollution and the downstream axios effects. Review application logs, APM traces, and error monitoring for TypeError exceptions originating from axios mergeConfig.js or utils.js, especially if they appear suddenly after requests containing suspicious object keys such as __proto__, constructor, or prototype. Inspect web access logs, API gateway logs, WAF events, and request bodies for attempted prototype-pollution payloads. Review outbound HTTP proxy, egress gateway, service mesh, and downstream service logs for unusual headers added to requests from affected applications, particularly headers not normally emitted by the service or values matching user-supplied input. In Node.js services, examine crash logs and stack traces for synchronous axios failures. Correlate suspicious inbound requests with subsequent outbound requests made by the same application instance or request context. There are no known threat actors or KEV exploitation campaigns reported for this issue, so detection should be behavior-based rather than actor-specific.

• __proto__
• constructor.prototype
• prototype.polluted
• node_modules/axios/lib/core/mergeConfig.js
• node_modules/axios/lib/utils.js
• TypeError
• Getter must be a function
• Setter must be a function
• Object.defineProperty
• axios/lib/core/mergeConfig
• axios/lib/utils
• package-lock.json axios 0.31.
• package-lock.json axios 1.15.
• yarn.lock axios@0.31
• yarn.lock axios@1.15
• pnpm-lock.yaml axios@0.31
• pnpm-lock.yaml axios@1.15

What your security team should do

• Inventory all applications and packages that include axios, prioritizing internet-facing services, API gateways, SSR/Node.js backends, serverless functions, and applications that process untrusted JSON or form input.
• Upgrade axios to 0.32.0 or later, or 1.16.0 or later, and ensure lockfiles and deployed artifacts contain the fixed version, including transitive dependency copies.
• Hunt for and patch upstream prototype-pollution vulnerabilities in the same applications, especially unsafe deep merge, query-string parsing, YAML/JSON processing, and object path assignment libraries.
• Add dependency policy controls that fail builds on vulnerable axios versions and known prototype-pollution libraries.
• Review outbound header allowlists for sensitive service-to-service calls so unexpected inherited headers cannot influence authentication, authorization, routing, or caching decisions.
• Monitor application logs for sudden TypeError spikes in axios request paths and network telemetry for unexpected outbound headers.
• Because this is not KEV-listed, has low EPSS, and requires a chained condition, prioritize remediation through normal dependency update cycles unless the application also has known prototype-pollution exposure or handles high-trust outbound requests.