Axios: Header Injection via Prototype PollutionGHSA-6chq-wfr3-2hj9
HIGHGHSA-6chq-wfr3-2hj9 is a high-severity (CVSS 7.4) CWE-113 vulnerability in axios. A fix is available for axios — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6chq-wfr3-2hj9.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
axiosnpmDescription
Summary
A prototype pollution gadget exists in the Axios HTTP adapter (lib/adapters/http.js) that allows an attacker to inject arbitrary HTTP headers into outgoing requests. The vulnerability exploits duck-type checking of the data payload, where if Object.prototype is polluted with getHeaders, append, pipe, on, once, and Symbol.toStringTag, Axios misidentifies any plain object payload as a FormData instance and calls the attacker-controlled getHeaders() function, merging the returned headers into the outgoing request.
The vulnerable code resides exclusively in lib/adapters/http.js. The prototype pollution source does not need to originate from Axios itself — any prototype pollution primitive in any dependency in the application's dependency tree is sufficient to trigger this gadget.
Prerequisites:
A prototype pollution primitive must exist somewhere in the application's dependency chain (e.g., via lodash.merge, qs, JSON5, or any deep-merge utility processing attacker-controlled input). The pollution source is not required to be in Axios. The application must use Axios to make HTTP requests with a data payload (POST, PUT, PATCH).
Details
The vulnerability is in lib/adapters/http.js, in the data serialization pipeline:
// lib/adapters/http.js
} else if (utils.isFormData(data) && utils.isFunction(data.getHeaders)) {
headers.set(data.getHeaders());
// ...
}
Axios uses two sequential duck-type checks, both of which can be satisfied via prototype pollution:
1. utils.isFormData(data) — lib/utils.js
const isFormData = (thing) => {
let kind;
return thing && (
(typeof FormData === 'function' && thing instanceof FormData) || (
isFunction(thing.append) && (
(kind = kindOf(thing)) === 'formdata' ||
(kind === 'object' && isFunction(thing.toString) && thing.toString() === '[object FormData]')
)
)
)
}
2. utils.isFunction(data.getHeaders) — Duck-type for form-data npm package
// Returns true if Object.prototype.getHeaders is a function
utils.isFunction(data.getHeaders)
PoC
// Simulate Prototype Pollution
Object.prototype[Symbol.toStringTag] = 'FormData';
Object.prototype.append = () => {};
Object.prototype.getHeaders = () => {
const headers = Object.create(null);
(.... Introduce here all the headers you want ....)
return headers;
};
Object.prototype.pipe = function(d) { if(d&&d.end)d.end(); return d; };
Object.prototype.on = function() { return this; };
Object.prototype.once = function() { return this; };
// Legitimate application code
const response = await axios.post('https://internal-api.company.com/admin/delete',
{ userId: 42 },
{ headers: { 'Authorization': 'Bearer VALID_USER_TOKEN' } }
);
Impact
- Authentication Bypass (CVSS: C:H)
- Session Fixation (CVSS: I:H)
- Privilege Escalation (CVSS: C:H, I:H)
- IP Spoofing / WAF Bypass (CVSS: I:H)
Note on Scope: There is an argument to promote this from S:U to S:C (Scope: Changed), which would raise the score to 10.0. In some architectures, Axios is commonly used for service to service communication where downstream services trust identity headers (Authorization, X-Role, X-User-ID, X-Tenant-ID) forwarded from upstream API gateways. In this scenario, the vulnerable component (Axios in Service A) and the impacted component (Service B, which acts on the injected identity) are under different security authorities. The injected headers cross a trust boundary, meaning the impact extends beyond the security scope of the vulnerable component, the CVSS v3.1 definition of a Scope Change. We conservatively score S:U here, but maintainers should evaluate which one applies better here.
Recommended Fix
Add an explicit own-property check in lib/adapters/http.js:
- } else if (utils.isFormData(data) && utils.isFunction(data.getHeaders)) {
- headers.set(data.getHeaders());
+ } else if (utils.isFormData(data) && utils.isFunction(data.getHeaders) &&
+ Object.prototype.hasOwnProperty.call(data, 'getHeaders')) {
+ headers.set(data.getHeaders());
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | axios | ≥ 1.0.0&&< 1.15.1 | 1.15.1npm install axios@1.15.1 |
| 📦npm | axios | all versions | 0.31.1npm install axios@0.31.1 |
Affected Products
axiosaxiosDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for axios, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update axios to 1.15.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6chq-wfr3-2hj9 is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for GHSA-6chq-wfr3-2hj9 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| HawtIO HawtIO 4.4.0 | axios | RHSA-2026:25089 |
| Red Hat Ansible Automation Platform 2.6 for RHEL 9 | automation-platform-ui-0:2.6.10-1.el9ap | RHSA-2026:34160 |
| Cluster Observability Operator 1.5 | cluster-observability-operator/distributed-tracing-console-plugin-pf4-rhel9:1781116645 | RHSA-2026:26010 |
| multicluster engine for Kubernetes 2.10 | multicluster-engine/console-mce-rhel9:1780917531 | RHSA-2026:24536 |
| multicluster engine for Kubernetes 2.11 | multicluster-engine/console-mce-rhel9:1780910888 | RHSA-2026:25271 |
| multicluster engine for Kubernetes 2.6 | multicluster-engine/console-mce-rhel9:1778511348 | RHSA-2026:17657 |
| multicluster engine for Kubernetes 2.8 | multicluster-engine/console-mce-rhel9:1778383863 | RHSA-2026:17699 |
| multicluster engine for Kubernetes 2.9 | multicluster-engine/console-mce-rhel9:1778532610 | RHSA-2026:19109 |
Frequently Asked Questions
Is GHSA-6chq-wfr3-2hj9 in your dependencies?
Find it across npm, including transitive dependencies.