Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 2.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HTTPX2 can automatically add a Content-Length header to a request that already contains a caller-supplied Transfer-Encoding header. The resulting HTTP/1.1 request contains both framing headers, which can create an ambiguous message boundary and enable request smuggling or connection desynchronization when processed by intermediaries that disagree about which header takes precedence. Details When a request body has a known size, HTTPX2's content encoder returns a default Content-Length. Request.prepare() applies each default header with setdefault(), which only checks whether that same header is already present. It does not check whether the mutually exclusive Transfer-Encoding header is present. For example: The request contains both: On an HTTP/1.1 connection, the body is serialized using chunked transfer coding while both headers are sent on the wire. This violates HTTP message-framing requirements. Fixed-size byte, JSON, form, and known-length multipart bodies can reach…
Recommended action: Upgrade to 2.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HTTPX2 serializes the per-file Content-Type and custom headers supplied through the files= tuple API directly into the multipart/form-data body without validating custom header names or values. An attacker who can influence upload metadata passed to HTTPX2 can use CR or LF characters to terminate a multipart part header and inject additional part headers or end the part header block early. Details The three-element file tuple accepts (filename, content, contenttype), and the four-element form accepts (filename, content, contenttype, headers). FileField.renderheaders() interpolates the supplied header names and values between CRLF delimiters without validating them. For example: The generated body contains an attacker-injected part header: The same issue affects names and values in the custom header mapping from the four-element tuple. Field names and filenames are serialized through a separate escaping path and do not permit CRLF header injection. Impact Applications are…
Recommended action: Upgrade to 2.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: On…
Recommended action: Upgrade to 2.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.