CVE-2026-69198

What it actually does

CVE-2026-69198 is a logic flaw in the JavaScript ip-address library versions 10.1.1 through affected 10.2.x builds before the fixed release. Special-use address classification methods such as isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() rely on isInSubnet(). When an attacker supplies an IP address with an artificially broad CIDR suffix, such as /0, the classification path incorrectly short-circuits and returns false because the supplied address mask is shorter than the reference subnet mask. The parsed address still represents the real internal or special-use IP, but the library reports it as non-special. Applications that use these methods to decide whether a user-supplied destination is safe can therefore misclassify internal, loopback, link-local, metadata-service, or otherwise restricted addresses as external. The main technical consequence is bypass of IP-based trust-boundary checks, most notably SSRF protections, allow/deny lists, internal-network access controls, webhook destination validation, proxy destination validation, and URL fetch filters.

Why it matters to the business

If an exposed application depends on the affected library for network destination validation, an unauthenticated remote attacker may be able to make the application connect to internal services that were intended to be unreachable from the internet. This can lead to cloud metadata exposure, internal service discovery, access to administrative interfaces, leakage of credentials or tokens, and abuse of trusted server-side network position. The issue is not known to be in CISA KEV, is not currently associated with ransomware campaigns, has low EPSS at the time of assessment, and has no reported mature public exploitation, but it should still be prioritized wherever the affected library is used in SSRF-relevant code paths. Red Hat Grafana package streams are listed as affected, which increases operational relevance for organizations using packaged Grafana deployments or downstream components that inherit the vulnerable dependency.

How an attack unfolds

An attacker first identifies an application feature that accepts a user-controlled IP address, URL, webhook endpoint, callback target, proxy destination, integration endpoint, or similar network destination. The application parses or validates the supplied address using the affected ip-address library and relies on methods such as isPrivate(), isLoopback(), isLinkLocal(), isULA(), or getType() to reject internal destinations. The attacker then submits an internal or special-use destination with a CIDR suffix that suppresses classification, for example an internal address with /0 appended. Because the library incorrectly treats the address as non-special, the application may allow the request. The same parsed value can still resolve to or be used as the actual internal target, allowing the server-side component to connect to loopback, RFC1918 networks, link-local cloud metadata addresses, service-discovery endpoints, or other restricted resources. Successful exploitation depends on the application actually using the vulnerable classification results for a security decision and then performing a server-side network request based on the attacker-controlled input.

How to fix it

Upgrade all affected uses of the ip-address JavaScript library to the fixed version 10.2.2 or later, and rebuild/redeploy applications so the corrected dependency is actually loaded at runtime. For Red Hat packaged Grafana streams, apply RHSA-2026:50826 or later: grafana12-4-main fixed in 12.4.6-0.3.hum1 and grafana13-1-main fixed in 13.1.1-0.5.2.hum1. Where direct dependency upgrades are not immediately possible, add defense-in-depth validation outside the vulnerable classification methods: normalize and parse destinations, reject any user-supplied CIDR suffix unless explicitly required, independently block loopback, private, link-local, multicast, unspecified, broadcast, ULA, CGNAT, and cloud metadata ranges, and enforce egress controls at the network layer. Do not rely solely on application-level URL or IP classification for SSRF prevention. Use outbound proxy allowlists, deny access to metadata services from workloads that do not require them, and resolve DNS and re-check the final connection IP immediately before connecting to prevent bypasses through redirects or DNS rebinding.

How to confirm the fix worked

Confirm fixed exposure by inventorying dependency manifests and lockfiles for ip-address versions 10.1.1 through vulnerable 10.2.x builds and verifying that runtime artifacts resolve to 10.2.2 or later. For packaged Grafana deployments, verify that installed packages match or exceed 12.4.6-0.3.hum1 for grafana12-4-main or 13.1.1-0.5.2.hum1 for grafana13-1-main, or that RHSA-2026:50826 has been applied. Add a regression test that parses representative restricted addresses with a /0 suffix and asserts that the application rejects them before any outbound connection is attempted. Test IPv4 and IPv6 cases, including loopback, RFC1918, link-local metadata, multicast, unspecified, CGNAT, and ULA examples. Also validate network-layer controls by attempting blocked outbound connections from the application runtime and confirming they are denied even if application validation fails.

Typical attack path

1. Find an internet-facing feature that accepts a destination address, URL, webhook, callback, proxy target, import source, or integration endpoint.
2. Test whether the feature blocks obvious internal destinations such as loopback, private RFC1918 addresses, IPv6 ULA, or link-local metadata addresses.
3. Submit the same class of destination with a broad CIDR suffix such as /0 to trigger incorrect special-use classification in the vulnerable ip-address library.
4. Observe whether the application accepts the destination even though the underlying address remains internal or otherwise restricted.
5. Use the server-side request capability to access internal services, cloud metadata endpoints, administrative ports, or service-discovery interfaces.
6. Extract reachable data, credentials, tokens, configuration, or service responses, or pivot to additional internal targets if the application exposes response content or timing behavior.

How to detect it

To determine whether this was already exploited, review logs for features that accept user-supplied network destinations: webhook creation/update logs, callback URL validation logs, URL fetch/import logs, proxy request logs, integration connector logs, SSRF protection deny/allow logs, application access logs, reverse proxy logs, outbound proxy logs, DNS resolver logs, cloud metadata access logs, and workload egress flow logs. Focus on requests where the submitted destination contains a CIDR suffix, especially /0, and where the base IP belongs to loopback, private RFC1918, link-local, CGNAT, multicast, unspecified, broadcast, IPv6 ULA, or cloud metadata ranges. Correlate accepted validation events with subsequent outbound connections from the application to internal IPs, 169.254.169.254, 127.0.0.0/8, ::1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10, fe80::/10, or fc00::/7. Investigate unusual response-size changes, error messages from internal services, metadata token requests, redirects that end at internal addresses, and repeated probing across adjacent internal addresses. There are no universal host artifacts for this vulnerability because exploitation occurs through application input handling and outbound network behavior, so detection depends heavily on application and egress telemetry.

• /0
• 127.0.0.1/0
• 0.0.0.0/0
• localhost/0
• ::1/0
• ::/0
• 10.0.0.1/0
• 172.16.0.1/0
• 192.168.0.1/0
• 169.254.169.254/0
• 169.254.170.2/0
• 100.64.0.1/0
• fe80::1/0
• fc00::1/0
• fd00::1/0
• metadata.google.internal/0
• latest/meta-data
• /latest/meta-data/
• /computeMetadata/v1/
• Metadata-Flavor: Google
• X-aws-ec2-metadata-token
• 169.254.169.254/latest/meta-data
• 169.254.169.254/0/latest/meta-data

What your security team should do

• Inventory applications and packaged products that include the ip-address JavaScript library, with priority on internet-facing services that accept URLs, IPs, webhooks, callbacks, import sources, proxy targets, or integration endpoints.
• Patch affected Red Hat Grafana packages to the RHSA-2026:50826 fixed builds and upgrade direct npm usage of ip-address to 10.2.2 or later.
• Search code for security decisions based on isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), getType(), or isInSubnet(), and review whether user-supplied CIDR suffixes can influence those checks.
• Add automated tests for SSRF defenses using restricted destinations with /0 and other unexpected CIDR suffixes.
• Deploy or tighten egress allowlisting so application servers cannot directly reach cloud metadata, loopback-only services, internal admin interfaces, or sensitive private network ranges unless explicitly required.
• Review recent logs for user-supplied destinations containing CIDR suffixes, especially /0, combined with internal, loopback, link-local, or metadata-service addresses.
• Because the CVE is not currently KEV-listed and EPSS is low, prioritize based on exposure and SSRF blast radius rather than the global exploitation score alone.