Summary
HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies
httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.
The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.
Details
The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.
For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:
import httpx2
with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
with client.websocket(
"wss://service.example/private?token=query-secret",
headers={"Authorization": "Bearer header-secret"},
cookies={"session": "cookie-secret"},
) as websocket:
websocket.send_text("private message")
On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:
GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret
Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.
A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.
RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.
Mitigation
Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.
If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.
Impact
An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.
Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.
CVE-2026-84381 has a CVSS score of 8.1 (High). The vector is reachable from an adjacent network, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.10.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
httpcore2 to 2.10.0 or later; httpx2 to 2.10.0 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-84381? CVE-2026-84381 is a high-severity security vulnerability in httpcore2 (pip), affecting versions < 2.10.0. It is fixed in 2.10.0.
- How severe is CVE-2026-84381? CVE-2026-84381 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by CVE-2026-84381?
httpcore2(pip) (versions < 2.10.0)httpx2(pip) (versions >= 2.6.0, < 2.10.0)
- Is there a fix for CVE-2026-84381? Yes. CVE-2026-84381 is fixed in 2.10.0. Upgrade to this version or later.
- Is CVE-2026-84381 exploitable, and should I be worried? Whether CVE-2026-84381 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-84381 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-84381?
- Upgrade
httpcore2to 2.10.0 or later - Upgrade
httpx2to 2.10.0 or later
- Upgrade