HTTPX2 vulnerabilities

HTTPX2 before version 2.12.0 fully inflates each gzip, deflate, br, or zstd network chunk before yielding bounded pieces to the application. A 64 KiB compressed chunk can expand to approximately 64 MiB in one intermediate allocation, causing severe memory pressure or out-of-memory termination even when streaming. Fixed in version 2.12.0.

HTTPX2 before 2.10.0 fails to start TLS when using SOCKS5 proxy for wss origins because the TLS upgrade condition only recognizes https. HTTPX2 exposes this via Client.websocket() and AsyncClient.websocket() from 2.6.0 to 2.9.1, allowing plaintext transmission without certificate verification. Fixed in httpcore2 2.10.0 and HTTPX2 2.10.0.

In HTTPX2 prior to version 2.11.0, a vulnerability was found in Request._prepare() in src/httpx2/httpx2/_models.py. It can add a body-derived Content-Length header to a request that already contains a caller-supplied Transfer-Encoding header because its setdefault() processing checks each default header independently rather than treating the two framing headers as mutually exclusive. This can allow request smuggling or connection desynchronization.

In HTTPX2 prior to version 2.11.0, a vulnerability was found in FileField.render_headers() in src/httpx2/httpx2/_multipart.py. It directly interpolates attacker-controlled content_type values and custom headers from the files= tuple into multipart/form-data part headers without validating header names or values. CR or LF characters can terminate a part header, inject additional part headers, or end the part header block early, allowing a downstream multipart parser to treat attacker-supplied lines as genuine headers and potentially alter part semantics or bypass header-based checks.

In HTTPX2 from version 2.5.0 until 2.10.0, a vulnerability was found in the Server-Sent Events parser in src/httpx2/httpx2/_sse.py. The _SSELineDecoder.decode() method repeatedly copies and rescans buffered text when an attacker-controlled or compromised SSE endpoint splits one unterminated line across many response chunks. The total processing work grows quadratically with the line length, allowing a crafted stream to consume excessive CPU and block a synchronous worker or asynchronous event loop.