CVE-2026-59939 in httplib2info

Summary

by MITRE • 07/08/2026

httplib2 is a comprehensive HTTP client library for Python. Prior to 0.32.0, httplib2 performs unbounded decompression of HTTP response bodies encoded with Content-Encoding: gzip or deflate in _decompressContent in httplib2/init.py, allowing a malicious or compromised HTTP server to return a small compressed payload that expands to an arbitrarily large size in memory and causes MemoryError or OOM-kill in the client process. This issue is fixed in version 0.32.0.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 07/08/2026

The httplib2 library represents a widely-used Python HTTP client implementation that facilitates communication with web services and APIs. This particular vulnerability affects versions prior to 0320 where the library exhibits insecure handling of compressed HTTP responses through its internal decompression mechanism. The flaw exists within the _decompressContent function located in httplib2/init.py, which processes Content-Encoding headers without implementing proper bounds checking on decompressed data sizes. When a malicious or compromised server sends a small compressed payload with gzip or deflate encoding, the library will attempt to decompress this content without limiting the resulting memory consumption, creating a potential denial of service vector.

The technical nature of this vulnerability stems from the absence of input validation and resource limitation mechanisms during decompression operations. The library's design assumes that decompressed content will remain within reasonable size parameters, but this assumption fails when confronted with maliciously crafted compressed data. An attacker can exploit this by crafting a compressed payload that expands to gigabytes or even terabytes of uncompressed data, while the original network transmission remains minimal in size. This creates an asymmetric resource consumption scenario where network bandwidth requirements are negligible compared to memory allocation demands during decompression.

The operational impact of this vulnerability extends beyond simple denial of service conditions, as it can lead to complete application crashes and system instability. When the client process encounters such oversized decompressed content, it typically results in MemoryError exceptions or triggers operating system Out-of-Memory kill mechanisms that terminate the entire process. This behavior affects any application utilizing httplib2 for HTTP communication, particularly those handling untrusted web services or APIs where response content cannot be fully controlled or validated. The vulnerability is especially concerning in environments where httplib2 is used for automated data processing or in server applications where resource exhaustion could affect service availability.

This vulnerability aligns with CWE-400, which categorizes unchecked resource consumption as a weakness involving insufficient bounds checking for resource allocation. From an adversary perspective, this represents a straightforward remote code execution or availability attack pattern that fits within the ATT&CK framework under the T1499 technique category for network denial of service. The exploitation requires minimal skill and resources, as it only necessitates control over a malicious HTTP server to send specifically crafted compressed content. Organizations using httplib2 should immediately implement version 0.32.0 or later, which includes proper bounds checking and memory limitation mechanisms. Additional mitigations may include network-level controls such as proxy configurations that enforce maximum response size limits, application-level input sanitization for HTTP responses, and monitoring systems to detect unusual memory consumption patterns. The fix implemented in version 0.32.0 demonstrates proper defensive programming practices by introducing bounded decompression algorithms that prevent unlimited memory allocation during content expansion operations.

Responsible

GitHub M

Reservation

07/07/2026

Disclosure

07/08/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!