Update dependency httpx2 to v2.12.0 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
httpx2 (changelog)	2.9.1 → 2.12.0

---

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

CVE-2026-84381 / GHSA-7mj9-2mp8-4m2p

More information

Details

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:

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.

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.

Severity

• CVSS Score: 8.1 / 10 (High)
• Vector String: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

References

• https://github.com/pydantic/httpx2/security/advisories/GHSA-7mj9-2mp8-4m2p
• https://nvd.nist.gov/vuln/detail/CVE-2026-84381
• https://github.com/pydantic/httpx2/pull/1104
• https://github.com/pydantic/httpx2/commit/fb008dd700b761d955210d9692475c3e2f379453
• https://github.com/pydantic/httpx2/releases/tag/v2.10.0
• https://github.com/advisories/GHSA-7mj9-2mp8-4m2p

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

HTTPX2: Quadratic SSE line buffering can cause CPU denial of service

CVE-2026-84378 / GHSA-f2fp-rgf2-35cp

More information

Details

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

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

Severity

• CVSS Score: 5.9 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/pydantic/httpx2/security/advisories/GHSA-f2fp-rgf2-35cp
• https://nvd.nist.gov/vuln/detail/CVE-2026-84378
• https://github.com/pydantic/httpx2/pull/1071
• https://github.com/pydantic/httpx2/pull/1117
• https://github.com/pydantic/httpx2/commit/cbfc0e04ef6507da29ccbb3b9c2e5b23dd693414
• https://github.com/pydantic/httpx2/releases/tag/v2.10.0
• https://github.com/advisories/GHSA-f2fp-rgf2-35cp

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

HTTPX2: Multipart part header injection via unvalidated file Content-Type and custom headers

CVE-2026-84379 / GHSA-h4x7-gw46-3wm6

More information

Details

Summary

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, content_type), and the four-element form accepts (filename, content, content_type, headers). FileField.render_headers() interpolates the supplied header names and values between CRLF delimiters without validating them.

For example:

import httpx2

request = httpx2.Request(
    "POST",
    "https://example.com/upload",
    headers={"Content-Type": "multipart/form-data; boundary=BOUNDARY"},
    files={
        "file": (
            "safe.txt",
            b"payload",
            "text/plain\r\nX-Injected: true",
        )
    },
)

print(request.read().decode())

The generated body contains an attacker-injected part header:

--BOUNDARY
Content-Disposition: form-data; name="file"; filename="safe.txt"
Content-Type: text/plain
X-Injected: true

payload
--BOUNDARY--

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 affected when they pass attacker-controlled upload metadata into the per-file content_type or custom headers arguments. The receiving server interprets injected lines as genuine multipart part headers. Depending on how that server validates and processes uploads, this can alter part semantics or bypass checks based on part headers.

This does not split the outer HTTP request: the injected headers are contained within the multipart body. The concrete security impact therefore depends on the downstream multipart parser and application behavior.

Mitigation

Upgrade to HTTPX2 2.11.0 or later. Patched versions reject forbidden control characters in multipart part header names and values and raise ValueError before serializing the request.

If upgrading is not immediately possible, applications should validate custom multipart header names as HTTP field-name tokens. They should reject NUL, CR, LF, other C0 controls except horizontal tab, and DEL in per-file content types and custom header values before passing them to HTTPX2.

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

• https://github.com/pydantic/httpx2/security/advisories/GHSA-h4x7-gw46-3wm6
• https://nvd.nist.gov/vuln/detail/CVE-2026-84379
• https://github.com/pydantic/httpx2/pull/1142
• https://github.com/pydantic/httpx2/commit/de96d810ee4e309d118982fe7084a46a2bcd600d
• https://github.com/pydantic/httpx2/releases/tag/v2.11.0
• https://github.com/advisories/GHSA-h4x7-gw46-3wm6

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

HTTPX2: Conflicting Content-Length and Transfer-Encoding headers can be auto-generated

CVE-2026-84380 / GHSA-pf96-p4fj-6566

More information

Details

Summary

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:

import httpx2

request = httpx2.Request(
    "POST",
    "http://example.com/",
    headers={"Transfer-Encoding": "chunked"},
    content=b"test 123",
)

print(request.headers)

The request contains both:

Transfer-Encoding: chunked
Content-Length: 8

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 the affected path.

Streaming bodies with an explicit Content-Length are not affected in current HTTPX2 releases because the automatically generated Transfer-Encoding is already suppressed in that direction.

Impact

An attacker may be able to use the conflicting framing headers as a request-smuggling or desynchronization primitive. Exploitation requires an application to pass attacker-controlled request framing headers and associated body data to HTTPX2, use HTTP/1.1, and communicate through a proxy or origin that accepts conflicting headers and interprets them differently from another hop.

Depending on the downstream infrastructure, successful exploitation could interfere with requests sharing a persistent connection, bypass front-end routing or authorization decisions, or poison responses or caches. Applications that do not forward attacker-controlled Transfer-Encoding headers are not directly exposed.

Mitigation

Upgrade to HTTPX2 2.11.0 or later. Patched versions treat Content-Length and Transfer-Encoding as mutually exclusive when applying automatically generated request headers.

If upgrading is not immediately possible, remove Transfer-Encoding and other hop-by-hop framing headers from untrusted input before constructing outbound requests. Applications acting as proxies should derive outbound framing from the body rather than forwarding inbound Content-Length or Transfer-Encoding headers.

Severity

• CVSS Score: 5.6 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

References

• https://github.com/pydantic/httpx2/security/advisories/GHSA-pf96-p4fj-6566
• https://nvd.nist.gov/vuln/detail/CVE-2026-84380
• https://github.com/pydantic/httpx2/pull/1137
• https://github.com/pydantic/httpx2/commit/829b93a2393212996f613e635261f777d9ec6eab
• https://github.com/pydantic/httpx2/releases/tag/v2.11.0
• https://github.com/advisories/GHSA-pf96-p4fj-6566

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

HTTPX2: Streaming response decompression does not bound peak memory (decompression amplification)

CVE-2026-84382 / GHSA-8xx6-hgc6-gc2m

More information

Details

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.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/pydantic/httpx2/security/advisories/GHSA-8xx6-hgc6-gc2m
• https://nvd.nist.gov/vuln/detail/CVE-2026-84382
• https://github.com/pydantic/httpx2/pull/1126
• https://github.com/pydantic/httpx2/commit/4fd0c70a3f207c618b145934792f791bccfb39f8
• https://github.com/pydantic/httpx2/releases/tag/v2.12.0
• https://github.com/advisories/GHSA-8xx6-hgc6-gc2m

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

pydantic/httpx2 (httpx2)

v2.12.0

Compare Source

Highlights

🛡️ Bounded response decompression

httpx2 now decodes gzip, deflate, Brotli, and Zstandard responses incrementally. Each decode step emits at most 1 MiB, so streaming a highly compressed response no longer requires materializing an entire inflated network chunk in memory (#​1126).

📦 Shared Zstandard API

Python 3.13 and earlier now use backports.zstd, which provides the same bounded incremental decompression API as compression.zstd on Python 3.14 and later (#​1146).

httpx2

Changed

• Use backports.zstd for Zstandard decoding on Python 3.13 and earlier by @​Kludex in #​1146

Fixed

• Bound peak memory while streaming compressed responses and close response streams when decoding fails by @​Kludex in #​1126

httpcore2

No changes since 2.11.0. Version bumped to stay in lockstep with httpx2.

Full Changelog: pydantic/httpx2@v2.11.0...v2.12.0

v2.11.0

Compare Source

Highlights

🌐 Public origin API

httpx2 now includes an immutable and hashable Origin value object, available through URL.origin. It provides normalized scheme, host, and effective port comparisons without including URL paths, queries, fragments, or credentials (#​1134).

🛠️ Request compatibility and validation

• Explicit Transfer-Encoding headers now take precedence over body-derived Content-Length headers (#​1137).
• Deprecated status code aliases are available again (#​1135).
• Multipart part headers are validated before serialization (#​1142).

httpx2

Added

• Add the public Origin value object and URL.origin property by @​Kludex in #​1134

Changed

• Require Brotli 1.2.0 or later for the brotli extra by @​Kludex in #​1141

Fixed

• Restore deprecated status code aliases by @​Kludex in #​1135
• Extract HTTP/2 release notes from changelog headings correctly by @​Kludex in #​1136
• Respect explicit Transfer-Encoding headers and expose buffered request body lengths to WSGI applications by @​Kludex in #​1137
• Validate multipart part header names and values before serialization by @​Kludex in #​1142

httpcore2

Changed

• Cache sniffio availability instead of importing it on every synchronization call by @​mbeijen in #​1132

Full Changelog: pydantic/httpx2@v2.10.0...v2.11.0

v2.10.0

Compare Source

Highlights

🚀 Performance and memory improvements

• Sending large HTTP/2 request bodies no longer copies the body quadratically - sending a 256 MiB body went from ~36s to under 0.1s (#​1127).
• SSE parsing is up to 35x faster on highly fragmented streams (#​1117).
• Cookie extraction is now skipped for responses without a Set-Cookie header, making typical requests roughly 8% faster (#​1107).

🕸️ WebAssembly / Emscripten support

httpx2 now runs on Pyodide / Emscripten, using a JavaScript fetch-based transport defined in httpx2-jsfetch (#​1119, #​1114). Thanks @​hoodmane!

httpx2

Added

• Add support for running on WebAssembly / Emscripten via Pyodide by @​hoodmane in #​1119
• Add max_event_size to cap SSE event buffering by @​Kludex in #​1071
• Add RFC 9110 status code constants by @​mbeijen in #​1069
• Add support for Python 3.15 by @​hugovk in #​1090

Changed

• Improve SSE chunk buffering performance by @​Kludex in #​1117
• Skip cookie extraction without Set-Cookie by @​Kludex in #​1107
• Return str | None instead of Any from Headers.get by @​ItsDrike in #​1121

Fixed

• Enforce WebSocket max message size across fragments by @​Kludex in #​1085
• Ignore unsolicited and duplicate Pong frames by @​Kludex in #​1122

httpcore2

Added

• Add support for Python 3.15 by @​hugovk in #​1090

Changed

• Avoid quadratic copying when sending large HTTP/2 request bodies by @​Kludex in #​1127

Fixed

• Propagate the original exception instead of raising KeyError when an HTTP/2 stream fails by @​yhay81 in #​1093
• Start TLS for the wss scheme in SOCKS5 proxy connections by @​Kludex in #​1104

🙏 New Contributors

• @​ccbest made their first contribution in #​1096
• @​dependabot[bot] made their first contribution in #​1103
• @​bagowix made their first contribution in #​1111
• @​aldbr made their first contribution in #​1108
• @​dsfaccini made their first contribution in #​1110
• @​yhay81 made their first contribution in #​1093
• @​laisbsc made their first contribution in #​1092
• @​hoodmane made their first contribution in #​1114
• @​ItsDrike made their first contribution in #​1121

Full Changelog: pydantic/httpx2@v2.9.1...v2.10.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.