GHSA-8xx6-hgc6-gc2m: SSRF

Published Sep 8, 2026
·
Updated

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.

Affected Software

1 affected componentFixes available
pip/httpx2<2.12.0
2.12.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/httpx2 to a version that resolves this vulnerability.

    Fixed in 2.12.0
  2. Upgrade

    Upgrade HTTPX2 to a version that resolves this vulnerability.

    Fixed in 2.12.0

Event History

Sep 8, 2026
Advisory Published
via GitHub·08:48 PM
Data Sourced
via GitHub·08:48 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which applications are most exposed to this issue?

Applications that fetch resources from untrusted or attacker-influenced servers are exposed. Examples include webhook receivers, link unfurlers, crawlers, SSRF-reachable fetchers, and clients that follow redirects.

2

Does streaming a response keep memory usage bounded?

No. Before version 2.12.0, each compressed network read was fully decompressed into an intermediate allocation before content was yielded, so streaming did not prevent transient large allocations.

3

What does an attacker need to trigger the issue?

An attacker needs the application to fetch a malicious compressed HTTP response using gzip, deflate, Brotli, or Zstandard encoding. No authentication or user interaction is required beyond causing the application to issue the request.

4

Which versions are affected?

HTTPX2 versions before 2.12.0 are affected.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203