CVE-2026-84381

HTTPX2 (via its httpcore2 transport) fails to start TLS for wss:// WebSocket connections tunneled through a SOCKS5 proxy, because the TLS upgrade condition in the SOCKS proxy handling only recognizes https and does not recognize wss. The flaw is reachable through Client.websocket() and AsyncClient.websocket() in HTTPX2/httpcore2 versions 2.6.0 through 2.9.1 when connecting to a wss origin via a SOCKS5 proxy. As a result, the opening handshake, query parameters, Authorization headers, cookies, and subsequent WebSocket frames cross the proxy path in plaintext without certificate verification, allowing an attacker controlling or observing that path to read or modify traffic and impersonate the WebSocket server. Any Python application using HTTPX2 for WebSocket connections over a SOCKS5 proxy is affected, while users who do not combine wss with a SOCKS5 proxy are not exposed. No public proof-of-concept or in-the-wild exploitation is known, EPSS is low (0.1% over 30 days), and the issue is not in CISA's KEV catalog.

What to do: Upgrade to httpcore2 2.10.0 and HTTPX2 2.10.0 or later, which restore TLS negotiation for wss through SOCKS5 proxies. Until upgraded, avoid using Client.websocket()/AsyncClient.websocket() for wss:// origins reached via SOCKS5 proxies, or ensure sensitive material (Authorization headers, cookies, query parameters) is not sent over those connections. Audit applications and proxy configurations for WebSocket use over SOCKS5 to determine whether credentials or data traversed the proxy in plaintext.