{"id":"CVE-2026-107285","aliases":["GHSA-3wp9-xfwm-rjjf"],"url":"https://o3.security/vulnerability/CVE-2026-107285","summary":"AsyncHttpClient: WebSocket proxy credentials sent to the origin server over a CONNECT tunnel","details":"### Impact\nWhen 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.\n\n### Affected versions\n* 3.x: up to and including 3.0.11\n* 2.x: up to and including 2.16.0\n\n### Patches\nFixed 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://.\n\n### Workarounds\nDo not use proxy authentication together with ws:// requests through an HTTP proxy, or use wss:// instead.\n\n### Details\nThe 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://.\n\nNote 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.","published":"2026-10-07T21:28:34.620Z","modified":"2026-10-21T09:39:31.813716968Z","cvss":{"score":5.9,"severity":"MEDIUM","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"},"epss":null,"cisaKev":null,"exploitsKnown":null,"affectedPackages":[{"ecosystem":"Maven","name":"org.asynchttpclient:async-http-client","fixedVersion":"3.0.12"},{"ecosystem":"Maven","name":"org.asynchttpclient:async-http-client","fixedVersion":"2.16.1"}],"fix":{"url":"https://github.com/AsyncHttpClient/async-http-client/commit/6e9cb75a9b7259353f983fc90ca28b1da3742e18","label":"AsyncHttpClient/async-http-client@6e9cb75"},"references":[{"type":"WEB","url":"https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-2.16.1"},{"type":"WEB","url":"https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-3.0.12"},{"type":"ADVISORY","url":"https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-3wp9-xfwm-rjjf"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/107xxx/CVE-2026-107285.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-107285"},{"type":"FIX","url":"https://github.com/AsyncHttpClient/async-http-client/commit/6e9cb75a9b7259353f983fc90ca28b1da3742e18"},{"type":"FIX","url":"https://github.com/AsyncHttpClient/async-http-client/commit/c4feab0f7f86d61505a48e40d383c8a375a22e18"},{"type":"PACKAGE","url":"https://github.com/AsyncHttpClient/async-http-client"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-10-21T09:39:31.813716968Z"}}