GHSA-pjwm-pj3p-43mv CVE-2026-44492
axios's shouldBypassProxy does not recognize IPv4-mapped IPv6 addresses, allowing NO_PROXY bypass (incomplete fix for CVE-2025-62718)
- Severity
- 8.6 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 12.28%
- Chance of exploitation in the next 30 days. Higher than 96.18% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
1.16.0- Upgrade axios to this version or later
Description
Summary
shouldBypassProxy, introduced in v1.15.0 to fix CVE-2025-62718, does not normalise IPv4-mapped IPv6 addresses. When NO_PROXY lists an IPv4 address such as 127.0.0.1 or 169.254.169.254, a request URL using the IPv4-mapped IPv6 form (::ffff:7f00:1, ::ffff:a9fe:a9fe) still routes through the configured proxy. Node.js resolves these addresses to the underlying IPv4 host, so the request reaches the internal service via the proxy rather than being blocked.
Details
lib/helpers/shouldBypassProxy.js (v1.15.0):
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);
// normalizeNoProxyHost strips brackets and trailing dots, but not ::ffff: prefix
return hostname === entryHost || (isLoopback(hostname) && isLoopback(entryHost));
The WHATWG URL parser canonicalises http://[::ffff:127.0.0.1]/ to hostname [::ffff:7f00:1]. After bracket-stripping: ::ffff:7f00:1. This string does not match 127.0.0.1 in NO_PROXY and is not in LOOPBACK_ADDRESSES, so shouldBypassProxy returns false and the proxy is used. proxy-from-env (called before shouldBypassProxy) has the same gap - it does not equate ::ffff:7f00:1 with 127.0.0.1 - so neither layer catches the bypass.
PoC
// NO_PROXY=127.0.0.1,localhost,::1 HTTP_PROXY=http://attacker:8080
import shouldBypassProxy from 'axios/lib/helpers/shouldBypassProxy.js';
// All three should return true (bypass proxy). Only the first two do.
console.log(shouldBypassProxy('http://127.0.0.1/')); // true [OK]
console.log(shouldBypassProxy('http://[::1]/')); // true [OK]
console.log(shouldBypassProxy('http://[::ffff:127.0.0.1]/')); // false <- bypass
console.log(shouldBypassProxy('http://[::ffff:7f00:1]/')); // false <- bypass
Node.js routes ::ffff:7f00:1 to 127.0.0.1:
// net.connect({ host: '::ffff:7f00:1', port: 80 }) reaches a service
// bound to 127.0.0.1:80 — confirmed on Node.js v24, Linux and macOS.
Cloud metadata SSRF: ::ffff:a9fe:a9fe = ::ffff:169.254.169.254. If NO_PROXY=169.254.169.254 is set to block IMDS access, a request to http://[::ffff:a9fe:a9fe]/latest/meta-data/ bypasses it.
Fix
Canonicalise IPv4-mapped IPv6 in normalizeNoProxyHost before any comparison:
const ipv4MappedDotted = /^::ffff:(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$/i;
const ipv4MappedHex = /^::ffff:([0-9a-f]{1,4}):([0-9a-f]{1,4})$/i;
function hexToIPv4(a, b) {
const hi = parseInt(a, 16), lo = parseInt(b, 16);
return `${hi >> 8}.${hi & 0xff}.${lo >> 8}.${lo & 0xff}`;
}
const normalizeNoProxyHost = (hostname) => {
if (!hostname) return hostname;
if (hostname[0] === '[' && hostname.at(-1) === ']')
hostname = hostname.slice(1, -1);
hostname = hostname.replace(/\.+$/, '').toLowerCase();
let m;
if ((m = hostname.match(ipv4MappedDotted))) return m[1];
if ((m = hostname.match(ipv4MappedHex))) return hexToIPv4(m[1], m[2]);
return hostname;
};
Impact
Any application that sets NO_PROXY to exclude internal or metadata endpoints and uses an HTTP/HTTPS proxy can have those exclusions bypassed by a URL using IPv4-mapped IPv6 notation. The attacker must control the request URL. In cloud environments with instance metadata services, this can lead to credential exfiltration.
Affected versions
npm
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
axios npm → 1.16.0
- npm
npm install axios@1.16.0- yarn
yarn add axios@1.16.0- pnpm
pnpm add axios@1.16.0
Severity breakdown
CVSS 3.1 8.6
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-289: Authentication Bypass by Alternate Name
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
How to prevent it
- Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
CWE-918: Server-Side Request Forgery (SSRF)
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
References
Advisories
Packages
Other links
- github.com/axios/axios/security/advisories/GHSA-pjwm-pj3p-43mv
- access.redhat.com/errata/RHSA-2026:36611
- access.redhat.com/errata/RHSA-2026:36754
- access.redhat.com/errata/RHSA-2026:36820
- access.redhat.com/errata/RHSA-2026:36882
- access.redhat.com/errata/RHSA-2026:36883
- access.redhat.com/errata/RHSA-2026:40119
- access.redhat.com/errata/RHSA-2026:40138
- access.redhat.com/errata/RHSA-2026:40262
- access.redhat.com/errata/RHSA-2026:41031
- access.redhat.com/errata/RHSA-2026:41055
- access.redhat.com/errata/RHSA-2026:41064
- access.redhat.com/errata/RHSA-2026:41066
- access.redhat.com/security/cve/CVE-2026-44492
- bugzilla.redhat.com/show_bug.cgi
- security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-44492.json
- access.redhat.com/errata/RHSA-2026:20889
- access.redhat.com/errata/RHSA-2026:20938
- access.redhat.com/errata/RHSA-2026:26234
- access.redhat.com/errata/RHSA-2026:27044
- access.redhat.com/errata/RHSA-2026:27063
- access.redhat.com/errata/RHSA-2026:28964
- access.redhat.com/errata/RHSA-2026:29082
- access.redhat.com/errata/RHSA-2026:29197
- access.redhat.com/errata/RHSA-2026:30650
- access.redhat.com/errata/RHSA-2026:30651
- access.redhat.com/errata/RHSA-2026:33005
- access.redhat.com/errata/RHSA-2026:33155
- access.redhat.com/errata/RHSA-2026:33160
- access.redhat.com/errata/RHSA-2026:33163
- access.redhat.com/errata/RHSA-2026:33173
- access.redhat.com/errata/RHSA-2026:33183
- access.redhat.com/errata/RHSA-2026:33574
- access.redhat.com/errata/RHSA-2026:34766
- access.redhat.com/errata/RHSA-2026:36108
- access.redhat.com/errata/RHSA-2026:41928
- access.redhat.com/errata/RHSA-2026:41951
- access.redhat.com/errata/RHSA-2026:42078
- access.redhat.com/errata/RHSA-2026:42085
- access.redhat.com/errata/RHSA-2026:42142
- access.redhat.com/errata/RHSA-2026:42146
- access.redhat.com/errata/RHSA-2026:42796
- access.redhat.com/errata/RHSA-2026:43052
- access.redhat.com/errata/RHSA-2026:46885
- access.redhat.com/errata/RHSA-2026:46903
- access.redhat.com/errata/RHSA-2026:50300
- access.redhat.com/errata/RHSA-2026:54188
- access.redhat.com/errata/RHSA-2026:57191
- access.redhat.com/errata/RHSA-2026:59833
- access.redhat.com/errata/RHSA-2026:60520
- access.redhat.com/errata/RHSA-2026:66488
- access.redhat.com/errata/RHSA-2026:66545
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-44g4-m2mj-wpvx Axios: CIDR-form NO_PROXY entries are ignored, causing proxy exclusion bypass for internal IP ranges | Medium | Also affects axios |
| GHSA-x97p-jq2g-jp4f Axios: Prototype Pollution Gadget in axios toFormData Options | High | Also affects axios |
| GHSA-vh66-26gq-q6x8 Axios: Prototype pollution gadget in fetch adapter can alter outbound requests | Medium | Also affects axios |
| GHSA-r4gj-5m52-g5wh Axios: maxRedirects: 0 is not enforced by the fetch adapter, allowing redirect-based SSRF | High | Also affects axios |
| GHSA-mghh-pgcx-3jjj Axios: ReDoS (O(N²)) in shouldBypassProxy host normalization, reachable via untrusted redirect Location | High | Also affects axios |
| GHSA-m8m8-qj5v-23w3 Axios: Node HTTP adapter prototype-pollution gadget allows request socket hijack via inherited createConnection | High | Also affects axios |
| GHSA-j8rh-479h-cp32 Axios: Header Injection via Inherited headers After Minimal Interceptor | Medium | Also affects axios |
| GHSA-c29m-xwm3-cm6r Axios: ReDoS in fromDataURI data: URL parser freezes the Node event loop (DoS) | High | Also affects axios |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor