CVE-2026-84381: 
Python vulnerability analysis and mitigation

CVE-2026-84381 is a cleartext transmission vulnerability in HTTPX2 and its underlying transport library httpcore2 (by Pydantic) that causes WebSocket Secure (wss://) connections routed through a SOCKS5 proxy to be transmitted without TLS encryption. The flaw affects httpcore2 versions before 2.10.0 and HTTPX2 versions 2.6.0 through 2.9.1. It was published on September 2, 2026, with a fix released in both httpcore2 2.10.0 and HTTPX2 2.10.0. The vulnerability carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, Red Hat).

The root cause is a missing scheme check in the SOCKS5 proxy connection handlers (CWE-319: Cleartext Transmission of Sensitive Information). In both _sync/socks_proxy.py and _async/socks_proxy.py, the TLS upgrade condition evaluated only scheme == b"https", omitting b"wss". After the SOCKS5 handshake completes, the raw stream is passed directly to the HTTP/1.1 connection handler, which writes the WebSocket upgrade request — including URL query parameters, Authorization headers, cookies, and all subsequent frames — in plaintext without performing a TLS handshake or certificate verification. The fix, merged in PR #1104, changes the condition to scheme in (b"https", b"wss") in both the synchronous and asynchronous code paths (GitHub Advisory, Fix Commit).

An attacker with the ability to control or observe the SOCKS5 proxy path can intercept the plaintext WebSocket opening handshake and all subsequent frames, exposing URL query parameters, Authorization headers, cookies, and application-level messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification is also skipped, enabling a malicious or compromised SOCKS proxy to impersonate the WebSocket server and inject or alter messages in both directions. Only wss:// connections routed through a SOCKS5 proxy are affected; direct wss:// connections and https:// requests through SOCKS5 are not impacted (GitHub Advisory).

No public proof-of-concept exploit code exists and no in-the-wild exploitation has been reported as of the disclosure date (Feedly). The EPSS score is approximately 0.079%, reflecting a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires network-adjacent positioning — specifically, the ability to control or observe traffic on the SOCKS5 proxy path — making opportunistic mass exploitation unlikely but targeted interception feasible in shared or untrusted proxy environments (GitHub Advisory).

1. Identify target applications: Locate Python applications using HTTPX2 versions 2.6.0–2.9.1 (or httpcore2 < 2.10.0) that route wss:// WebSocket connections through a SOCKS5 proxy.
2. Position on the proxy path: Gain control of or passive observation access to the SOCKS5 proxy (e.g., via a compromised proxy server, a rogue proxy on a shared network, or a man-in-the-middle position between the client and the proxy).
3. Observe the SOCKS5 handshake: Allow the client to complete the SOCKS5 negotiation normally. Because TLS is never initiated, the subsequent WebSocket upgrade request arrives in plaintext.
4. Capture sensitive data: Read the plaintext HTTP/1.1 GET upgrade request, which includes the full URL path and query parameters (e.g., token=query-secret), Authorization headers (e.g., Bearer header-secret), and Cookie headers.
5. Optionally impersonate the server: If controlling the proxy, return a forged 101 Switching Protocols response to establish a bidirectional plaintext WebSocket session, enabling reading and modification of all subsequent frames in both directions (GitHub Advisory).

• Network: Plaintext HTTP/1.1 GET requests with Upgrade: websocket headers observed on the SOCKS5 proxy path to destinations using wss:// URIs; absence of a TLS ClientHello record immediately following the SOCKS5 handshake where one would be expected.
• Logs: Application logs showing successful WebSocket connections to wss:// endpoints via a SOCKS5 proxy on HTTPX2 versions 2.6.0–2.9.1 without TLS negotiation errors (indicating the plaintext path was silently used).
• Network: Unexpected 101 Switching Protocols responses originating from the SOCKS5 proxy address rather than the intended WebSocket server, which may indicate server impersonation.

Upgrade HTTPX2 to version 2.10.0 or later and httpcore2 to version 2.10.0 or later; these versions correctly initiate TLS for both https and wss schemes in SOCKS5 proxy connections (GitHub Release). If an immediate upgrade is not possible, avoid routing wss:// connections through a SOCKS5 proxy — use direct secure WebSocket connections instead, or apply additional network-layer encryption (e.g., VPN) to protect the proxy path (GitHub Advisory, Red Hat Bugzilla).

The vulnerability was reported by researcher maxisbey and the advisory was published by Kludex (a Pydantic maintainer) on August 18, 2026, with the fix merged on August 2, 2026 — prior to the CVE's public disclosure on September 2, 2026. Red Hat tracked the issue via Bugzilla (Bug 2527704) with a high severity rating, and NixOS opened a security tracking issue for affected packages (GitHub Advisory, Red Hat Bugzilla, Fix PR).