CVE-2025-4673

What it actually does

A flaw in the Java HTTP client implementation causes it to incorrectly persist the 'Proxy-Authorization' and 'Proxy-Authenticate' headers when following a cross-origin redirect. This means that if an application connects to a server through an authenticated proxy and is redirected to a different origin, the proxy credentials will be leaked to the new destination server.

Why it matters to the business

Exploitation of this vulnerability can lead to the theft of proxy credentials. These stolen credentials could be used by an attacker to gain unauthorized access to your network, bypass security controls, exfiltrate data, or pivot to other internal systems, potentially resulting in a significant data breach and operational disruption.

How an attack unfolds

An attacker would first need to entice a vulnerable Java application, which is configured to use an authenticated proxy, to make a request to a server under their control. This could be achieved through various means, such as compromising a legitimate website the application interacts with. When the application connects, the attacker's server responds with an HTTP redirect (e.g., 301 or 302) to a different domain, also controlled by the attacker. The vulnerable Java client follows this redirect but fails to strip the 'Proxy-Authorization' header, sending the sensitive proxy credentials directly to the attacker's second server, where they can be captured and abused.

How to fix it

To remediate this vulnerability, upgrade affected OpenJDK components to a patched version. For users of the specified Chainguard packages, upgrade to version 0.48.0-r2 or later. For other distributions, consult your vendor's security advisories for the appropriate patch for CVE-2025-4673. If immediate patching is not feasible, consider implementing strict egress filtering rules on the proxy to limit the domains that applications are allowed to connect to, reducing the risk of redirection to a malicious server.

How to confirm the fix worked

To confirm the vulnerability is patched, verify that the installed OpenJDK package version is at or above the fixed version specified by your vendor (e.g., `openjdk-21-openj9` version `0.48.0-r2`). To identify potentially exposed systems, inventory all Java applications that use the native HTTP client (`java.net.HttpURLConnection`) and are configured to use a proxy with authentication.

Typical attack path

1. An attacker sets up a malicious web server or compromises a legitimate one that a target application communicates with.
2. The attacker induces a vulnerable Java application to send an HTTP request to the server.
3. The application sends the request through its configured authenticated proxy, including the 'Proxy-Authorization' header.
4. The attacker's server responds with an HTTP redirect to a different, attacker-controlled origin.
5. The vulnerable Java client follows the redirect, erroneously forwarding the 'Proxy-Authorization' header containing credentials to the new origin.
6. The attacker's server at the new origin receives the request and logs the proxy credentials, completing the theft.

How to detect it

To detect potential exploitation, security teams should analyze web server and proxy logs. On web servers, look for any incoming requests that contain a 'Proxy-Authorization' header; this header should only be sent to proxies, so its presence in a request to an origin server is a strong indicator of compromise. In proxy logs, search for patterns where a client is redirected from an expected domain to an unrelated or suspicious external domain. Correlating these redirects with the User-Agent string for Java can help pinpoint vulnerable clients.

• HTTP access log entries on origin web servers containing the string 'Proxy-Authorization:'

What your security team should do

• Identify all systems running vulnerable versions of OpenJDK, prioritizing those that use an authenticated proxy for outbound connections.
• Apply the security patches provided by your Java vendor immediately, upgrading to a fixed version.
• As a precautionary measure, rotate credentials for all proxy accounts used by potentially vulnerable Java applications.
• Review proxy and web server logs for evidence of past exploitation, such as requests to origin servers containing a 'Proxy-Authorization' header.