CVE-2026-44495

What it actually does

Affected Axios versions process request configuration in a way that can consume inherited properties from JavaScript prototypes, specifically a polluted Object.prototype.transformResponse value. Axios is not the component that performs the initial prototype pollution; exploitation requires a separate flaw or attacker-controlled code path in the same JavaScript process that first modifies Object.prototype. Once that prerequisite exists, Axios may incorrectly treat the inherited transformResponse value as request configuration or as part of option validation, potentially altering response handling, weakening application logic, causing unexpected request behavior, or enabling data exposure depending on how the application uses Axios responses.

Why it matters to the business

The main risk is that an existing prototype-pollution weakness elsewhere in an application can become more damaging when paired with vulnerable Axios versions. In affected Node.js services or browser applications, this could lead to incorrect handling of HTTP responses, exposure of sensitive data returned by upstream services, or service instability. The CVSS score is high, but exploitation complexity is also high because Axios does not provide the initial pollution primitive. EPSS is currently low and it is not listed in CISA KEV or known ransomware use, so remediation should be prioritized based on whether affected applications also process untrusted JavaScript object input, merge user-controlled objects, or run security-sensitive Axios calls.

How an attack unfolds

An attacker first identifies an application path that allows prototype pollution in the same JavaScript runtime where Axios is later used. This could be through unsafe object merge, query-string parsing, JSON body processing, or another dependency that permits assignment to prototype-related keys. The attacker uses that separate weakness to set Object.prototype.transformResponse to an attacker-chosen value. When the application subsequently creates an Axios request using an affected version, Axios request configuration processing may read the inherited transformResponse property as if it were an explicit request option or validator input. The security impact then depends on the application: response transformation may be altered, validation assumptions may be bypassed, application logic may consume manipulated response data, or malformed processing may cause errors and availability impact. Because exploitation depends on chaining with another vulnerability, there is no single universal remote exploit pattern for Axios alone.

How to fix it

Upgrade Axios to a fixed version: use 0.31.1 or later for the 0.x line, or 1.15.2 or later for the 1.x line. Because exploitation requires an existing prototype-pollution primitive, also audit and remediate unsafe object merge, clone, parser, and deserialization code paths that accept untrusted input. Block or sanitize prototype-related keys such as __proto__, constructor, and prototype in request bodies, query parameters, headers-derived objects, and configuration objects. Where feasible, create request configuration objects with null prototypes, avoid relying on inherited properties, and use dependency versions that explicitly protect against prototype pollution. Rebuild and redeploy applications after dependency updates, including lockfile refreshes for package-lock.json, npm-shrinkwrap.json, yarn.lock, or pnpm-lock.yaml as applicable.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve Axios to 0.31.1 or later on the 0.x branch, or 1.15.2 or later on the 1.x branch. Use package manager tooling such as npm ls axios, yarn why axios, pnpm why axios, or software composition analysis to identify both direct and transitive Axios usage. In CI, fail builds that resolve vulnerable Axios versions. For runtime validation, exercise application flows that perform Axios requests while using test inputs containing __proto__, constructor, prototype, and transformResponse keys; confirm Object.prototype.transformResponse is not created and Axios behavior remains unchanged. Also verify that no application code or dependency path permits arbitrary writes to Object.prototype.

Typical attack path

1. Find an application using Axios from 0.19.0 before 0.31.1, or 1.x before 1.15.2.
2. Identify a separate prototype-pollution vector in the same JavaScript process, such as unsafe handling of __proto__, constructor, or prototype keys.
3. Submit crafted input that pollutes Object.prototype.transformResponse.
4. Trigger application functionality that performs an Axios request after the pollution has occurred.
5. Leverage Axios's inherited-property handling to influence response transformation or option validation.
6. Use the resulting behavior to expose data, bypass intended logic, or degrade service depending on application design.

How to detect it

There is no reliable Axios-specific exploitation artifact because the issue is a gadget that depends on a separate prototype-pollution vulnerability. Detection should focus on evidence that attackers attempted to pollute prototypes and set transformResponse before Axios requests were made. Review web access logs, API gateway logs, WAF events, application logs, request body capture where legally and operationally permitted, JavaScript error telemetry, and Node.js process logs. Look for inbound parameters, JSON keys, or encoded payloads containing __proto__, constructor, prototype, constructor.prototype, Object.prototype, and transformResponse. Investigate TypeError or Axios-related stack traces occurring after suspicious requests, especially errors mentioning transformResponse or unexpected non-function values in response transformation. In forensic analysis, inspect dependency lockfiles for vulnerable Axios versions and review heap snapshots or runtime instrumentation, if available, for unexpected Object.prototype.transformResponse values. Correlate suspicious prototype-pollution probes with subsequent requests that trigger server-side outbound HTTP calls or security-sensitive Axios workflows.

• Object.prototype.transformResponse
• __proto__[transformResponse]
• __proto__.transformResponse
• __proto__%5BtransformResponse%5D
• __proto__%2EtransformResponse
• constructor.prototype.transformResponse
• constructor%5Bprototype%5D%5BtransformResponse%5D
• constructor.prototype%5BtransformResponse%5D
• prototype.transformResponse
• "__proto__"
• "constructor"
• "prototype"
• "transformResponse"
• transformResponse
• TypeError: transformResponse
• axios
• node_modules/axios/package.json
• package-lock.json
• yarn.lock
• pnpm-lock.yaml

What your security team should do

• Inventory all applications and packages that include Axios, including transitive dependencies and bundled front-end assets.
• Prioritize upgrades for internet-facing services, Node.js backends handling untrusted JSON or query parameters, and applications with known prototype-pollution findings.
• Upgrade Axios to 0.31.1 or later, or 1.15.2 or later, and refresh lockfiles to prevent vulnerable transitive resolution.
• Search codebases for unsafe merge patterns and input parsing that allow __proto__, constructor, prototype, or transformResponse keys to reach object construction logic.
• Add SCA policy gates to block Axios versions from 0.19.0 before 0.31.1 and 1.x before 1.15.2.
• Add application-level protections that reject prototype-pollution keys in user-controlled objects.
• Review logs and telemetry for evidence of prototype-pollution probing, especially requests containing __proto__, constructor.prototype, prototype, or transformResponse parameters.
• Because EPSS is low and there is no KEV listing, treat this as important hardening unless a paired prototype-pollution exposure is present; if one is present, remediate urgently.