The Axios Security Vulnerability: How CVE-2023-45857 Silently Leaked Auth Tokens and What It Reveals About npm Dependency Risk

Axios is the HTTP client library that most JavaScript developers reach for without thinking twice. With over 50 million weekly npm downloads and a transitive dependency footprint that spans hundreds of thousands of applications, it is as close to ubiquitous as a single npm package gets. React apps use it. Vue apps use it. Node.js microservices use it. It has been the default choice for making HTTP requests in JavaScript for nearly a decade.

In November 2023, a critical vulnerability was disclosed in axios: CVE-2023-45857, CVSS score 8.8 (High). The vulnerability allowed attackers to perform CSRF-style attacks that caused axios to forward the HTTP Authorization header — containing bearer tokens, API keys, and session credentials — to a different, attacker-controlled origin than the one the application intended to contact.

The vulnerability was silent. No error. No log entry. The auth token simply went to the wrong place.

What the Vulnerability Actually Did

To understand CVE-2023-45857, you need to understand how HTTP redirects and browser security policies interact with custom headers.

When a browser's native fetch() API follows a redirect from origin A to a different origin B, it strips sensitive headers like Authorization before making the second request. This is correct security behavior — you authenticated with server A, and server B should not automatically receive that token.

Axios, which implements its own HTTP handling layer, failed to apply this same check before a fix was introduced in version 1.6.0. When axios followed a redirect that crossed origins, it forwarded all headers from the original request — including Authorization — to the redirected destination.

The attack scenario

An attacker who can cause an axios-based application to make a request to a URL they control — or who can cause a server they influence to issue a redirect — can receive the application's Authorization header at their own endpoint. The typical CSRF attack chain looks like this:

1. Application makes an axios request to api.legitimate.com/resource with Authorization: Bearer <token>
2. The server at api.legitimate.com issues a 302 redirect to attacker-controlled.com/capture
3. Axios follows the redirect without stripping headers
4. Axios sends the request to attacker-controlled.com/capture with Authorization: Bearer <token> included
5. Attacker captures the token and uses it to authenticate as the victim

Server-side axios exposure

The risk is not limited to client-side web apps. Many Node.js microservices use axios to make requests to internal APIs — often with service account tokens or API keys in the Authorization header. A server-side SSRF vulnerability that allows an attacker to influence the URL that axios fetches could chain into auth token theft via redirect manipulation. This is a particularly high-severity scenario because service account tokens often have broader permissions than user tokens.

What the Fix Looked Like

Prior to 1.6.0, axios had no origin check before forwarding headers on redirect. The fix introduced a comparison between the original request origin and the redirect destination. If they differ, sensitive headers are stripped — matching the behavior of native browser APIs.

Checking your current version

Timeline of the Disclosure

The Broader npm Supply Chain Problem

The axios CVE is illustrative of a structural problem with npm dependency management that goes beyond any single library. Modern JavaScript applications routinely have hundreds or thousands of transitive dependencies — code written by individuals or small teams that your application trusts implicitly because it appears in your node_modules directory.

The scale of npm dependency risk

Consider what a typical medium-sized React application's dependency graph actually contains:

• 20–40 direct dependencies in package.json
• 500–1,500 total installed packages in node_modules
• Code maintained by hundreds of different authors
• Dependencies that themselves have dependencies — a chain of trust that extends multiple levels deep

Each of these packages is implicitly trusted with the ability to execute code in your environment, access environment variables, make network requests, and read the filesystem. A malicious or compromised package anywhere in that tree can exfiltrate secrets, install backdoors, or silently manipulate your application's behavior.

Recent npm supply chain incidents

The axios CVE was a vulnerability in legitimate code — a bug, not malicious intent. But the npm ecosystem has also faced deliberate supply chain attacks:

• ua-parser-js (2021): The maintainer's npm account was compromised. Attackers published malicious versions that installed cryptominers and credential stealers. The package had 7 million weekly downloads and was used by Facebook, Google, Microsoft, and Amazon products.
• colors and faker (2022): The maintainer intentionally sabotaged both packages, breaking applications that depended on them. Demonstrated that maintainer intent is itself a risk factor in open source dependency management.
• node-ipc (2022): Maintainer added code that deleted files on systems with Russian or Belarusian IP addresses — a politically motivated supply chain sabotage targeting applications using this dependency.
• Polyfill.io (2024): The polyfill.io domain was sold to a Chinese company which injected malicious JavaScript that was served to over 100,000 websites that referenced the CDN script. Applications that loaded axios via CDN alongside polyfill.io were potentially exposed to both this and the CVE-2023-45857 vulnerability window simultaneously.

What Your Application Security Review Should Cover

The axios CVE should prompt a broader review of how your application handles HTTP client security. Here is what a proper assessment looks like:

HTTP client configuration review

• Authorization header handling: Are auth headers set globally via axios interceptors or defaults? Any code that sets axios.defaults.headers.common['Authorization'] means every axios request in your application will carry that header — including to unintended third-party endpoints if a redirect is followed.
• Redirect behavior: Does your application need to follow redirects? If not, set maxRedirects: 0 explicitly. If yes, test whether redirects can be influenced by external input.
• SSRF surface: Any place where user-supplied or externally-influenced URLs are passed to axios is an SSRF candidate. This includes webhook URLs, avatar image fetching, URL preview generation, and proxy functionality.
• Timeout and error handling: Axios without explicit timeouts can be used in denial-of-service scenarios where requests hang indefinitely. Always set timeout.

Dependency security process

• Run npm audit in CI — fail builds on High and Critical findings, not just warn
• Use Dependabot or Renovate to automate dependency updates with PR-based review
• Pin exact versions in package-lock.json and commit it to version control
• Periodically review the full dependency tree for packages that have changed maintainers, been abandoned, or show unusual activity
• Consider using npm install --ignore-scripts in production to prevent postinstall scripts from executing during deployment

What Pentesters Look for in Applications Using Axios

When we test web applications that use axios, the CVE-2023-45857 vulnerability is one item on a longer checklist of HTTP client security issues. Here is what a comprehensive assessment examines:

SSRF via user-controlled URLs

If your application accepts a URL as user input and passes it to axios (webhook endpoints, import-from-URL features, link previews, avatar fetching), we test whether we can redirect that request to internal services. The axios redirect-following behavior made SSRF-to-credential-theft chains particularly attractive because the auth header came with the redirect.

Token leakage via open redirects

Open redirect vulnerabilities on your own domain become significantly more dangerous when your application uses axios with default headers. An attacker who finds an open redirect on api.yourapp.com/redirect?url=attacker.com can potentially capture authorization tokens from any authenticated request that follows that redirect.

Global header configuration review

Applications frequently set auth headers globally using axios interceptors without considering which requests should and should not carry those credentials. A proper code review maps all outbound HTTP requests from your application and verifies that sensitive headers are only attached to requests going to the intended authenticated endpoint.

• axios version >= 1.6.0 confirmed in package-lock.json and all dependency trees
• npm audit run in CI with failure on High/Critical findings
• No user-controlled URL parameters passed directly to axios without validation
• Authorization headers scoped to intended endpoints only — not set globally
• Redirect following disabled or limited where not needed
• Timeouts set on all axios requests
• Dependabot or Renovate enabled on repository
• No CDN-loaded scripts from third-party domains (or subresource integrity enforced)

The Lesson That Applies Beyond Axios

CVE-2023-45857 is not a story about axios being uniquely insecure. axios is a well-maintained library with active contributors and a fast response to the disclosure. The vulnerability was fixed within weeks of being reported and disclosed responsibly.

The lesson is about assumption of trust in the dependency ecosystem. Every package your application depends on — whether directly or transitively — is code you are executing in your environment. The security model of your application includes every package in node_modules. Most development teams do not review dependency code with the same rigor they apply to their own application code.

The organizations that handled the axios CVE well were the ones that already had:

• Automated dependency scanning that alerted on the new CVE within hours of disclosure
• A process for evaluating the exploitability of CVEs in their specific application context
• The ability to ship a dependency update through their pipeline within days, not weeks
• Application security testing that had already identified and addressed SSRF risk in their codebase

The organizations that were still running vulnerable axios versions months after the fix were the ones treating security as something that happens during audits rather than as a continuous engineering practice.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.