CVE-2026-107285: AsyncHttpClient: WebSocket proxy credentials sent to the origin server over a CONNECT tunnel
Impact When a ws:// request is routed through an HTTP proxy with proxy authentication configured, the client tunnels the connection with an HTTP CONNECT, the same as it does for https://. Once the tunnel is open, the WebSocket upgrade request that follows is sent through the tunnel directly to the origin server, not to the proxy. The proxy-auth gate and the companion request-target selection keyed only on whether the URI was secured, which is false for ws://, so the tunnelled upgrade request incorrectly carried the proxy's Proxy-Authorization header and an absolute-form request target meant for the proxy. Any origin server reached over a proxied ws:// connection, or anyone positioned on the origin side of the wire, could recover the proxy credentials: directly for Basic, or as a replayable and offline-crackable response for Digest.
Affected versions 3.x: up to and including 3.0.11 2.x: up to and including 2.16.0
Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The preemptive Proxy-Authorization header and the absolute-form request target are no longer attached to a tunnelled ws:// upgrade; a ws:// request is now treated like wss://.
Workarounds Do not use proxy authentication together with ws:// requests through an HTTP proxy, or use wss:// instead.
Details The proxy-auth gate in NettyRequestFactory#newNettyRequest and the sibling branch in requestUri() did not exclude WebSocket URIs, even though the CONNECT-tunnelling check in NettyRequestSender already tunnels ws:// through CONNECT exactly like https://.
Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.
Other sources
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 and 2.16.1, a proxied ws request is carried through CONNECT, but NettyRequestFactory.newNettyRequest and requestUri decide whether to attach proxy authentication and an absolute-form target only from whether the URI is secure. Because ws is not marked secure, the tunneled WebSocket upgrade sent to the origin includes the proxy's Proxy-Authorization value. Basic credentials are directly recoverable and Digest responses can be replayed or cracked offline. This issue is fixed in versions 3.0.12 and 2.16.1.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.asynchttpclient:async-http-clientto a version that resolves this vulnerability.Fixed in 2.16.1 - Upgrade
Upgrade
maven/org.asynchttpclient:async-http-clientto a version that resolves this vulnerability.Fixed in 3.0.12 - Upgrade
Upgrade
AsyncHttpClientto a version that resolves this vulnerability.Fixed in 3.0.13 - Compensating control
Do not use proxy authentication with ws:// requests through an HTTP proxy; use wss:// instead.
Event History
Frequently Asked Questions
Which deployments are exposed?
Java applications using AsyncHttpClient before 3.0.12 or 2.16.1 are exposed when they make WebSocket (ws) requests through a proxy using CONNECT and proxy authentication. The issue concerns ws requests, not the secure-URI path described for tunneled requests.
What does an attacker need to exploit this?
An attacker needs to receive or observe the tunneled WebSocket upgrade request at the origin server, where the proxy's Proxy-Authorization value is incorrectly included. No application privileges or user interaction are required according to the supplied vector, but exploitation has high attack complexity.
What credentials may be exposed?
Proxy Basic credentials are directly recoverable from the leaked Proxy-Authorization header. Proxy Digest authentication responses may be replayed or subjected to offline cracking.
What should be done if upgrading is not immediately possible?
Avoid making proxied ws requests with proxy authentication until AsyncHttpClient can be updated. The available fixes are version 3.0.12 and 2.16.1.
How can I determine whether exposure may already have occurred?
Review origin-server request logs or captured WebSocket upgrade requests for a Proxy-Authorization header on ws traffic that was sent through a CONNECT proxy. Its presence indicates that proxy authentication material was forwarded to the origin.