HTTPX2 CVE-2026-84381

Three concurrent conditions are required: (1) the application explicitly uses HTTPX2's Client.websocket() or AsyncClient.websocket() API (not generic HTTP requests), (2) the target URL uses the wss:// scheme, and (3) a SOCKS5 proxy is configured in the HTTPX2 client. Additionally, the attacker must occupy the adjacent network path - either controlling the SOCKS5 proxy itself, or positioned on the layer-2 segment between the client and the proxy where unencrypted traffic is visible. Exploitation is limited to HTTPX2 versions 2.6.0 through 2.9.1; applications using plain ws://, https://, or http:// are not affected. Applications routing wss:// connections through HTTP CONNECT proxies rather than SOCKS5 are also not affected. Standard https:// REST calls from the same client are unaffected regardless of proxy type.

The CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, score 8.1) accurately characterises the threat: an attacker must occupy the adjacent network segment on the path between the HTTPX2 client and its SOCKS5 proxy, but once there faces no complexity barrier, requires no credentials, and gains full read and write access to what should have been an encrypted channel. The AC:L rating is appropriate because no brute-force or race condition is required - the traffic simply flows in plaintext. The AV:A constraint meaningfully reduces real-world exposure compared to AV:N; exploitation requires controlling or passively monitoring a specific network hop (the proxy egress segment or the internal segment to the proxy). No EPSS score was provided in the input data, so probabilistic exploitation likelihood is not quantifiable from this dataset. KEV status is negative, and no public proof-of-concept has been published. However, the fix is a one-line change in a well-understood code path, and the vulnerability pattern (missing scheme in a TLS-upgrade guard) is easy to reproduce by anyone reading the advisory. Overall this is a genuine, exploitable MITM flaw for the narrow population of applications using wss:// over SOCKS5, but real-world impact is bounded by both the adjacent-network prerequisite and the early-adoption stage of the HTTPX2 library itself.

An attacker who controls or can passively monitor the network segment between the HTTPX2 client host and its configured SOCKS5 proxy intercepts the outbound connection intended for a wss:// endpoint. Because httpcore2 skips TLS negotiation on that tunnel, the attacker receives the WebSocket Upgrade HTTP request in cleartext - including any Authorization or Cookie headers - and can relay, read, or alter all subsequent WebSocket frames. The attacker can also present their own forged WebSocket responses without triggering a certificate error, since no TLS handshake and no certificate check ever occur.