Summary

When decoding a compressed response body (gzip, deflate, br, or zstd), HTTPX2 fully decompressed each network read before yielding content to the application. A small compressed input could therefore cause a large intermediate memory allocation, even when the application streamed the response to keep memory usage bounded.

Details

HTTPX2's default transport reads the socket in pieces of up to 64 KiB. Before 2.12.0, each piece was inflated completely into one intermediate allocation before any decompressed bytes were yielded.

At DEFLATE's maximum compression ratio of roughly 1032:1, a 64 KiB compressed chunk can expand to about 64 MiB in one allocation. Brotli and Zstandard responses can cause similarly large amplification. Streaming the response did not prevent these transient allocations.

Impact

Applications that fetch resources from untrusted or attacker-influenced servers - such as webhook receivers, link unfurlers, crawlers, SSRF-reachable fetchers, and redirect followers - can experience memory pressure or out-of-memory termination when processing a malicious compressed response. No authentication or user interaction is required beyond issuing a request to the server.

Mitigation

Upgrade to HTTPX2 2.12.0 or later. Patched versions decompress responses incrementally with bounded intermediate buffers, including responses with multiple content encodings.

Summary

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:

python 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.sendtext("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

text 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.

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.

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.

Summary

HTTPX2's Server-Sent Events (SSE) parser repeatedly copied and rescanned buffered text when a server split one unterminated line across many response chunks. The total work grows quadratically with the length of the line. An attacker-controlled or compromised SSE endpoint can exploit this behavior to consume excessive client CPU.

Details

Before version 2.10.0, HTTPX2 combined the complete pending SSE line with each newly received chunk and then scanned the combined text for line separators. If an SSE server sends a long line as many small chunks without a line separator, every chunk causes all previously received text to be copied and scanned again. For n fixed-size chunks, this results in O(n²) processing.

The behavior affects both httpx2.Client.sse() and httpx2.AsyncClient.sse(). Other response APIs do not use the SSE parsing path.

Impact

Applications that consume SSE from an attacker-controlled or compromised endpoint can experience excessive CPU usage. A crafted stream can block a synchronous worker or the asynchronous event loop that is consuming it, degrading availability for other work in that process. Confidentiality and integrity are not affected.

Mitigation

Upgrade to HTTPX2 2.10.0 or later. SSE parsing now accumulates incomplete line fragments and combines them only when necessary, making processing linear in the amount of received data. HTTPX2 2.10.0 also limits buffered SSE events to 1 MiB by default through maxeventsize.

If upgrading is not immediately possible, only consume SSE from trusted endpoints and enforce an external size or time budget on the stream.