CVE-2026-69192

What it actually does

This flaw is a parser differential in the JavaScript ip-address library before version 10.3.1. The library's Address4 parser accepts IPv4 octets with leading zeroes and interprets them as decimal, while common URL and network resolution components such as the WHATWG URL host parser, inet_aton, and getaddrinfo may interpret the same octets as octal. As a result, application-layer security checks can evaluate one destination while the underlying network stack connects to another. For example, a filter may treat 012.0.0.1 as the public address 12.0.0.1, while the outbound request actually reaches 10.0.0.1. Any application using Address4-derived methods such as isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), or correctForm() for trust-boundary decisions may incorrectly allow requests to internal, loopback, link-local, or otherwise restricted addresses. The primary technical consequence is SSRF filter bypass and unintended access to protected network endpoints.

Why it matters to the business

Applications that rely on the affected parsing behavior to validate user-supplied URLs or IP addresses may allow attackers to reach internal services that were intended to be blocked. In business terms, this can expose cloud metadata endpoints, internal APIs, administrative interfaces, monitoring systems, or other non-public services to unauthorized access through a vulnerable application. Although the EPSS score is currently low and the issue is not listed in CISA KEV, the bug is easy to trigger wherever affected validation logic is present and the vulnerable library is commonly embedded through downstream applications. For the listed Red Hat Grafana packages, patched builds are available, so remediation should be treated as a normal-priority security update unless the application accepts user-controlled outbound URLs, webhooks, data-source URLs, proxy targets, or similar network destinations, in which case priority should be raised.

How an attack unfolds

An attacker first identifies an application feature that accepts a URL, hostname, or IP address and then causes the server to make an outbound request, such as a webhook, URL preview, import function, callback URL, data-source configuration, proxy endpoint, or integration test. If the application uses the vulnerable ip-address Address4 parser to decide whether the destination is private, loopback, link-local, or otherwise disallowed, the attacker supplies an IPv4 address containing leading-zero octets. The validation layer decodes the address as decimal and may conclude that the destination is external and permitted. The actual HTTP client, URL parser, DNS/socket layer, or operating system resolver then interprets the same address differently, often as octal, and connects to an internal address. The attacker can then interact with internal services through the vulnerable server, potentially reading metadata, probing internal ports, invoking internal APIs, or accessing sensitive responses returned by the SSRF-capable feature.

How to fix it

Upgrade affected components to versions that include ip-address 10.3.1 or later. For the listed Red Hat Grafana packages, apply RHSA-2026:50826: grafana12-4-main fixed in 12.4.6-0.4.1.hum1 and grafana13-1-main fixed in 13.1.2-0.1.hum1. For applications that directly depend on the JavaScript ip-address package, update the package to version 10.3.1 or later and rebuild/redeploy all affected services and containers. As defense in depth, reject ambiguous IPv4 address forms at input boundaries, including octets with leading zeroes, hexadecimal notation, shortened IPv4 forms, integer-form IPv4 addresses, and mixed encodings. Normalize destinations using the same parser and resolver path that will be used for the actual connection, then enforce allow/deny decisions on the resolved canonical IP address immediately before connection. Prefer positive allowlists for outbound destinations where feasible, block access to loopback, RFC1918, link-local, multicast, carrier-grade NAT, and cloud metadata ranges at the egress layer, and apply network controls so SSRF-capable application components cannot reach sensitive internal services unnecessarily.

How to confirm the fix worked

Confirm that the deployed package or application build no longer contains ip-address versions earlier than 10.3.1. For Node.js projects, inspect lockfiles and runtime dependency trees using package manager tooling such as npm ls ip-address, yarn why ip-address, or pnpm why ip-address. For Red Hat Grafana deployments, verify the installed package versions are at least 12.4.6-0.4.1.hum1 for grafana12-4-main or 13.1.2-0.1.hum1 for grafana13-1-main, and confirm RHSA-2026:50826 has been applied. Functionally test URL/IP validation controls with leading-zero IPv4 inputs such as http://012.0.0.1/ and verify they are rejected or canonicalized consistently before any outbound connection is attempted. Also test representative private, loopback, link-local, and metadata-service targets using ambiguous notation and confirm that the application blocks them and that no outbound traffic reaches the decoded internal address.

Typical attack path

1. Find an application endpoint or feature that accepts a user-controlled URL, host, IP address, webhook, callback, proxy target, or data-source address.
2. Submit test payloads using IPv4 addresses with leading-zero octets, such as 012.0.0.1, to determine whether validation and connection behavior differ.
3. Use the decimal-versus-octal parsing mismatch to make the application classify the target as external while the network stack connects to an internal, loopback, link-local, or restricted address.
4. Reach internal services through the server-side request path, such as metadata endpoints, administrative interfaces, service discovery endpoints, monitoring APIs, or internal HTTP services.
5. Extract reachable sensitive data, enumerate internal network services, or perform follow-on actions through accessible internal APIs if responses or side effects are exposed.

How to detect it

Review logs for attempts to submit URLs or host values containing IPv4 octets with leading zeroes, especially in features that trigger outbound requests. Useful sources include application request logs, reverse proxy logs, WAF logs, API gateway logs, webhook or integration audit logs, Grafana access and server logs where relevant, outbound proxy logs, DNS logs, EDR network telemetry, cloud VPC flow logs, and firewall egress logs. Look for a pattern where an inbound request contains an ambiguous IPv4 literal such as 012.0.0.1 and the server subsequently makes an outbound connection to a private, loopback, link-local, or metadata address. Investigate outbound connections from application servers to 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, fc00::/7, or metadata service addresses after suspicious inbound requests. Because no public exploitation maturity or named threat actors are identified for this CVE, detection should focus on behavioral evidence of SSRF probing: repeated requests with unusual numeric IP encodings, blocked or failed validation attempts, internal port scanning through URL-fetching features, and unexpected application-originated HTTP requests to sensitive internal endpoints.

• 012.0.0.1
• http://012.0.0.1/
• https://012.0.0.1/
• 0177.0.0.1
• http://0177.0.0.1/
• 0251.0376.0251.0376
• http://0251.0376.0251.0376/
• 0300.0250.0000.0001
• http://0300.0250.0000.0001/
• 0254.0254.0254.0254
• http://0254.0254.0254.0254/
• 169.254.169.254
• http://169.254.169.254/
• metadata.google.internal
• latest/meta-data
• /latest/meta-data/
• /computeMetadata/v1/
• Metadata-Flavor: Google
• X-aws-ec2-metadata-token
• Address4('012.0.0.1')

What your security team should do

• Inventory services and applications that accept user-supplied URLs, hosts, IPs, webhooks, callbacks, data-source endpoints, or proxy targets and use the JavaScript ip-address library or affected downstream packages.
• Patch Red Hat Grafana packages to the fixed RHSA-2026:50826 builds: 12.4.6-0.4.1.hum1 for grafana12-4-main and 13.1.2-0.1.hum1 for grafana13-1-main.
• Update direct ip-address dependencies to version 10.3.1 or later and rebuild all containers, serverless packages, and bundled JavaScript artifacts that may carry older transitive versions.
• Add input validation that rejects ambiguous IPv4 literals, especially any dotted-quad octet with a leading zero.
• Review SSRF defenses to ensure destination authorization is performed on canonical resolved IPs using the same semantics as the connection path.
• Apply egress firewall or proxy controls to prevent application workloads from reaching loopback, private network ranges, link-local ranges, and cloud metadata IPs unless explicitly required.
• Search historical application, proxy, WAF, and outbound HTTP logs for leading-zero IPv4 address payloads to assess whether probing or exploitation occurred.
• Prioritize remediation higher for internet-facing applications, multi-tenant systems, integrations that return fetched content to users, and environments where application servers can reach sensitive internal services.