CVE-2025-22870

What it actually does

The vulnerability causes incorrect parsing of IPv6 addresses that include a zone ID. When matching hostnames against proxy exclusion lists (like the NO_PROXY environment variable), the zone ID can be misinterpreted as part of the hostname. This allows a crafted request to improperly match an exclusion rule, causing it to bypass the configured proxy. This can lead to unintended network traffic routing, potentially resulting in low-impact information disclosure or denial of service.

Why it matters to the business

This vulnerability allows for the bypass of network security controls implemented by proxies. An attacker could cause sensitive application traffic, which is intended to be routed through a secure and monitored proxy, to be sent directly to its destination, evading inspection, logging, and filtering. This can lead to information leakage, policy violations, and a weakened security posture by creating blind spots in network monitoring.

How an attack unfolds

An attacker with local access to a system or control over an application's network requests can exploit this vulnerability. The attacker first identifies the proxy exclusion rules configured in the environment, typically via the NO_PROXY variable. They then craft a network request to a destination using an IPv6 address that includes a specially formatted zone ID. This zone ID is designed to mimic a domain in the exclusion list. When the vulnerable application processes this request, it misinterprets the zone ID as part of the hostname, incorrectly matches it against the exclusion list, and consequently sends the traffic directly to the destination, bypassing the intended security proxy.

How to fix it

The primary remediation is to upgrade affected components to a version that correctly parses IPv6 addresses with zone IDs. For affected Red Hat Single Sign-On products, upgrade to version `15.0.4-1.redhat_00001.1.el8sso` or later. If patching is not immediately possible, a potential mitigation is to review and tighten `NO_PROXY` rules to be as specific as possible, avoiding broad wildcards that are easier to mimic. However, this is not a complete solution, and patching is strongly recommended.

How to confirm the fix worked

To validate the fix, configure a test environment with a proxy server and set the `NO_PROXY` environment variable to a wildcard domain (e.g., `*.example.com`). From an application running on this system, attempt to make a network request to a crafted IPv6 address with a zone ID that matches the wildcard, such as `http://[::1%25test.example.com]`. Monitor the proxy's access logs. If the request appears in the proxy logs, the system is correctly routing the traffic and is not vulnerable. If the request bypasses the proxy, the system is vulnerable.

Typical attack path

1. Attacker gains local access to a system or compromises an application that makes outbound network requests.
2. The attacker identifies the proxy exclusion rules, such as those defined in the `NO_PROXY` environment variable.
3. The attacker crafts a network request to a malicious or external destination using a specially formatted IPv6 address.
4. The crafted IPv6 address includes a zone ID that mimics a hostname pattern present in the proxy exclusion list.
5. The vulnerable application incorrectly parses the address, matches it against the exclusion list, and bypasses the configured proxy.
6. The request is sent directly to the attacker-controlled or external destination, evading security monitoring and filtering.

How to detect it

To detect potential historical exploitation, security teams should analyze network flow logs (e.g., VPC flow logs, firewall logs) for direct outbound connections from hosts that are configured to use a proxy for all or most traffic. Correlate these direct connections against proxy server logs to identify traffic that should have been proxied but was not. Additionally, search application and system logs for connection attempts to hostnames containing IPv6 addresses with a zone ID, specifically looking for the `%25` or `%` characters within the hostname string, which may indicate an attempt to trigger the parsing flaw.

• URL or hostname strings in logs containing an IPv6 address with a zone ID, such as `[...%25...]` or `[...%...]`.
• Network connections to hostnames that appear to be malformed IPv6 addresses containing domain names, for example: `[::1%25malicious-domain.com]`.

What your security team should do

• Prioritize patching affected systems, especially those in multi-tenant or less trusted environments where local access is a credible threat.
• Audit `NO_PROXY` environment variable configurations across your fleet to ensure they are as specific as possible and do not use overly broad wildcards.
• Review network egress logs for unexpected direct connections from servers that are supposed to route all traffic through a proxy, as this could indicate a bypass.