CVE-2026-69198: 
JavaScript vulnerability analysis and mitigation

CVE-2026-69198 is a logic flaw in the ip-address npm library (by beaugunderson) that allows a CIDR suffix appended to an IP address string to suppress all special-use classification, enabling bypass of SSRF and network trust-boundary filters. The vulnerability affects versions >= 10.1.1 and <= 10.2.1; versions before 10.1.1 do not expose the affected classification API. It was reported by @hi-im-glitchless, published to the GitHub Advisory Database on July 25, 2026, and assigned CVE-2026-69198 on August 3, 2026. The CVSS v4 base score is 6.9 (Medium) (Github Advisory).

The root cause (CWE-20: Improper Input Validation; CWE-918: SSRF) lies in isInSubnet() in src/common.ts, which short-circuits to false when the receiver's subnet mask is shorter than the reference range's mask. Because every special-use classifier (isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), getType()) delegates to isInSubnet(), appending a short CIDR suffix such as /0 to any internal address causes the guard to fire before any bit comparison occurs, returning false (i.e., "not internal"). Critically, correctForm() and the address object itself still resolve to the real internal target, so the server will actually connect to it. Exploitation requires an application that accepts a bare address string (not a full URL) and passes it directly to the Address4 or Address6 constructor before classifying — for example, webhook targets, proxy destinations, or allow/deny fields. A public proof-of-concept is included in the advisory (Github Advisory, Fix Commit).

Successful exploitation allows an attacker to bypass SSRF filters built on the affected classification methods, causing the server to make requests to internal destinations such as loopback services (127.0.0.1), RFC 1918 private ranges (10.x.x.x, 172.16.x.x, 192.168.x.x), link-local cloud metadata endpoints (169.254.169.254), CGNAT ranges, and IPv6 equivalents including ULA and IPv4-mapped addresses. The primary impact is high confidentiality exposure on subsequent systems (e.g., cloud instance metadata services that may expose credentials or configuration), while integrity and availability of the vulnerable system itself are not directly affected. This also nullifies the prior fix for GHSA-22jq-vg5j-6vgg, meaning IPv4-mapped and NAT64 addresses with a suffix revert to being misclassified as external (Github Advisory).

1. Identify a vulnerable application: Find an application using ip-address npm versions >= 10.1.1 and <= 10.2.1 that accepts user-supplied IP address strings (not full URLs) for SSRF filtering — such as webhook configuration fields, proxy destination inputs, or allow/deny lists.
2. Craft a suffixed internal address: Append a CIDR suffix shorter than the target range's prefix to an internal address. The universal bypass is /0 (e.g., 127.0.0.1/0, 169.254.169.254/0, 10.0.0.1/0, ::1/0). For more targeted bypasses, use a suffix shorter than the specific range (e.g., 10.0.0.5/7 bypasses the 10.0.0.0/8 private check).
3. Submit the crafted address: Supply the suffixed address string to the application's input field that accepts IP addresses for outbound requests.
4. Bypass classification: The application passes the string to new Address4(input) or new Address6(input) and calls classification methods (e.g., isPrivate(), isLoopback()). Due to the isInSubnet guard, all return false, and the address is treated as external/safe.
5. Trigger the internal request: The application proceeds to make an outbound request using correctForm() or the address value, which resolves to the real internal target (e.g., the cloud IMDS at 169.254.169.254), potentially exposing credentials, tokens, or internal service data (Github Advisory).

• Network: Outbound server-side HTTP requests to internal IP ranges (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, 100.64.0.0/10) or cloud metadata endpoints (169.254.169.254) originating from the application server process.
• Logs: Application access logs showing user-supplied address strings containing CIDR suffixes (e.g., patterns matching \d+\.\d+\.\d+\.\d+/\d+ or [0-9a-f:]+/\d+) in webhook, proxy, or destination fields; HTTP requests to http://169.254.169.254/latest/meta-data/ or similar IMDS paths in server-side request logs.
• Application Behavior: Unexpected responses from internal services returned to external users; error messages or data from loopback or metadata services appearing in application output.

Upgrade the ip-address npm package to version 10.2.2, which introduces a new isHostInSubnet() function that compares only the address's host bits against the reference range, independent of any CIDR suffix. All classifiers (isLoopback, isPrivate, isLinkLocal, isCGNAT, isMulticast, isUnspecified, isBroadcast, isULA, getType, etc.) now use isHostInSubnet(), while isInSubnet() retains correct subnet-containment semantics (v10.2.2 Release). If immediate upgrade is not possible, strip the CIDR suffix before classifying using addressMinusSuffix: const host = new Address4(new Address4(userInput).addressMinusSuffix); and classify host instead. Additionally, the advisory notes that these classification methods should be treated as one layer of SSRF defense — a robust guard must also resolve hostnames and validate the resolved IP at connection time to account for DNS rebinding and redirects (Github Advisory).

The advisory credits @hi-im-glitchless as the reporter. The GitHub Advisory notes that this vulnerability also defeats the prior fix for GHSA-22jq-vg5j-6vgg (released in 10.2.1), which addressed IPv4-mapped and NAT64 address classification — highlighting a pattern of incremental security improvements in this library's classification API. Tenable has published cloud and container security plugin coverage (plugin 445597) for this vulnerability (Github Advisory).