CVE-2026-69192: 
JavaScript vulnerability analysis and mitigation

CVE-2026-69192 is an octal-encoding bypass vulnerability in the ip-address npm library (by beaugunderson) that allows attackers to circumvent SSRF filters and network trust-boundary checks. The root cause is that Address4 accepts IPv4 octets with leading zeros and decodes them as decimal (e.g., 012 → 12), while the WHATWG URL host parser, inet_aton, and getaddrinfo all decode leading zeros as octal (e.g., 012 → 10). This disagreement means an application using the library to block internal addresses will classify 012.0.0.1 as public (12.0.0.1), while the actual network request reaches 10.0.0.1. All versions up to and including 10.3.0 are affected; version 10.3.1 contains the fix. The vulnerability carries a CVSS v4 base score of 7.7 (High) (Github Advisory, Feedly).

The defect is classified as CWE-20 (Improper Input Validation) and CWE-918 (Server-Side Request Forgery). In src/v4/constants.ts, the RE_ADDRESS regex used by Address4.parse contained the per-octet alternative [01]?[0-9][0-9]?, which permits a leading zero — so 012 passes validation. Downstream, every octet is decoded via parseInt(part, 10), yielding 12, while resolvers interpret the same string as octal 10. Because the flaw is in the parse gate itself, all downstream classifiers — isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm() — all operate on the mis-decoded value. Notably, Address6 already rejected this notation on its IPv4-in-IPv6 path, making Address4 the outlier. A proof-of-concept is included in the advisory: installing ip-address@10.3.0 and calling isBlocked('012.0.0.1') returns false (allowed), while fetch('http://012.0.0.1/') connects to 10.0.0.1 (Github Advisory).

The primary security impact is SSRF enablement: an attacker can supply an octal-ambiguous address (e.g., 012.0.0.1 or 012.012.012.012) to an application that uses ip-address for SSRF filtering, causing the filter to classify the address as public while the actual HTTP request reaches an internal RFC 1918 host (the entire 10.0.0.0/8 and 0.0.0.0/8 ranges are reachable via this technique). This can expose cloud instance metadata services, internal APIs, and other restricted endpoints. The CVSS v4 scoring reflects high subsequent-system confidentiality impact, acknowledging that internal services reachable via SSRF may expose sensitive data. Availability and integrity of the vulnerable system itself are not directly impacted (Github Advisory, Feedly).

1. Identify a target application: Find a web application that accepts user-supplied URLs or IP addresses and uses the ip-address npm library (versions ≤ 10.3.0) to validate or filter them for SSRF protection.
2. Craft an octal-ambiguous address: Construct an IPv4 address with a leading zero in one or more octets that maps to an internal RFC 1918 target — for example, 012.0.0.1 (resolves to 10.0.0.1) or 012.012.012.012 (resolves to 10.10.10.10).
3. Submit the crafted address: Supply the address as a user-controlled URL parameter (e.g., a webhook URL, image fetch URL, or proxy target). Because the address is a valid URL host, it passes standard URL parsing: new URL('http://012.0.0.1/').hostname returns '10.0.0.1'.
4. Bypass the SSRF filter: The application's guard calls Address4.isValid('012.0.0.1') (returns true) and new Address4('012.0.0.1').isPrivate() (returns false), so the request is classified as external and allowed.
5. Reach the internal target: The server issues the HTTP request, which the OS resolver decodes as octal, connecting to the actual internal host (e.g., 10.0.0.1 or a cloud metadata endpoint such as 169.254.169.254 if reachable via similar encoding).
6. Exfiltrate data: The server's response from the internal endpoint is returned to the attacker, potentially exposing credentials, metadata, or internal service data (Github Advisory).

• Network: Outbound HTTP requests from the application server to RFC 1918 addresses (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x) or cloud metadata endpoints (e.g., 169.254.169.254) that were not initiated by legitimate application logic.
• Logs: Application access logs showing user-supplied URL parameters containing IPv4 addresses with leading-zero octets (e.g., matching the pattern /\b0\d+\.\d+\.\d+\.\d+/ or specific values like 012.0.0.1, 012.012.012.012, 010.0.0.1).
• Logs: Server-side request logs showing connections to internal IP addresses immediately following receipt of requests containing octal-ambiguous address strings.
• Network: Unexpected DNS or HTTP traffic to cloud instance metadata services (e.g., http://169.254.169.254/latest/meta-data/) originating from the application process.

Upgrade the ip-address npm package to version 10.3.1, which tightens the RE_ADDRESS regex to reject octets with leading zeros and adds an explicit pre-check in Address4.parse that throws AddressError for any octet matching /^0\d/. If an immediate upgrade is not possible, apply the following input sanitization before passing any host string to Address4: if (host.split('.').some((octet) => /^0\d/.test(octet))) throw new Error('ambiguous address');. Additionally, the advisory recommends treating ip-address classifiers as one layer of SSRF defense only — a robust guard must also resolve hostnames and validate the resolved IP against the actual socket destination, accounting for DNS rebinding and redirects (Github Advisory, v10.3.1 Release).