How a simple hostname comparison flaw in Axios can let attackers bypass your proxy protection entirely and what to do about it.
A Security Alert Landed in My Inbox
A GitHub Dependabot alert flagged a critical security vulnerability in Axios across one of our repositories. The title read:
_Axios has a NO_PROXY Hostname Normalization Bypass Leads to SSRF
_
My first reaction was the usual: "How bad is this really?" After digging into it, reading the CVE, the GitHub advisory, the patch PR, and a related supply chain attack, it piqued my curiosity and I went into a rabbit hole to understand how something so simple can be dangerous.
What Is Axios? A Quick Recap
If you've written a Node.js or React app that makes HTTP requests, you've almost certainly used Axios. It's a promise-based HTTP client with over 70 million weekly downloads. It's everywhere - backends, frontends, CI pipelines, serverless functions. That ubiquity is precisely what makes vulnerabilities in it so impactful.
Understanding the Vulnerability: CVE-2025–62718
The Problem
Axios supports proxy configuration via environment variables like HTTP_PROXY and NO_PROXY.
The idea is simple:
- Requests to certain hosts (e.g., localhost, internal services) should bypass the proxy.
- Everything else goes through the proxy.
However, the issue lies in how Axios checks whether a hostname should bypass the proxy.
Instead of normalizing hostnames, Axios performs a direct string comparison.
This leads to a bypass.
For example:
- localhost → correctly bypasses proxy
- localhost. → treated as a different hostname
- ::1 → also bypasses incorrectly
Because of this, an attacker can manipulate hostnames to:
- Trick Axios into routing requests through a proxy
- Potentially reach internal services
- Trigger Server-Side Request Forgery (SSRF)
Why This Matters
SSRF is not just theoretical.
Once exploited, it can expose:
- Internal APIs
- Cloud metadata services
- Sensitive infrastructure endpoints
In modern environments, especially those using cloud providers, this can escalate quickly into credential exposure or full system compromise.
The Fix
After digging into the Axios repository, I found that this issue has been addressed.
The fix was introduced in:
Axios v1.15.0
You can review the patch here:
The update ensures that:
- Hostnames are normalized before comparison
- NO_PROXY rules behave as expected
An Important Side Note: The Axios Supply Chain Attack
While researching this CVE, I came across a separate but related incident worth being aware of.
In late March 2026, two npm versions of Axios -1.14.1 and 0.30.4 - were found to be malicious. A North Korean state actor (Sapphire Sleet) injected a fake dependency (plain-crypto-js@4.2.1) that automatically downloaded a remote access trojan during npm install. The Axios source code itself was untouched; the attack happened via a dependency added to the package manifest.
Microsoft published a detailed breakdown of the attack: Mitigating the Axios npm supply chain compromise
Safe versions to target:
- 1.14.0 -safe, no SSRF fix
- 1.15.0 -safe, includes the SSRF fix
Avoid 1.14.1 and 0.30.4 entirely.
How to Fix It
Step 1: Check your current version
npm list axios
Or inspect your lock file:
cat package-lock.json | grep '"axios"' -A 3
Step 2: Upgrade to 1.15.0
npm install axios@1.15.0
Step 3: Pin the version in package.json
This is the part most teams skip and it's important. If your package.json currently reads:
"axios": "^1.15.0"
That caret (^) allows npm to automatically upgrade axios to any newer minor or patch release - this can be good or bad depending on your usecase however it makes it easier for teams to pull in malicious releases easily. Change it to an exact pin:
"axios": "1.15.0"
Now axios will only upgrade if you explicitly change that number. No surprises.
Step 5: Commit both files
Always commit both package.json and package-lock.json together. The lock file is what actually controls what gets installed in CI and on other machines.
Broader Lessons
This issue is a reminder that:
- Security vulnerabilities are not limited to backend systems
- Frontend dependencies can introduce infrastructure level risks
- Regular audits and dependency reviews are essential
If your team uses Axios in a server-side context with proxy configuration, take 10 minutes today to check your version and upgrade. The fix is a one-liner. The risk of not doing it is not.
Have you updated your axios? Drop a comment below, curious how widespread the exposure is across teams.
Top comments (0)