GHSA-j5g9-f88f-gfj3

Summary

The httplib2 HTTP client library performs unbounded decompression of HTTP response bodies encoded with Content-Encoding: gzip or deflate. A malicious or compromised HTTP server can return a small compressed payload (approximately 150 KB) that expands to an arbitrarily large size in memory (150 MB or more), causing MemoryError or OOM-kill in the client process. This is a classic decompression bomb (zip bomb) attack against the HTTP client.

Any application using httplib2.Http().request() against untrusted or attacker-controlled HTTP endpoints is affected.

Details

Affected code: httplib2/__init__.py - _decompressContent() function

The decompression path has two unbounded operations:

1. gzip decompression (line 394):

   content = gzip.GzipFile(fileobj=io.BytesIO(new_content)).read()
   

   The .read() call with no size argument decompresses the entire gzip payload into a single in-memory bytes object. There is no limit on the decompressed size.

2. deflate decompression (line 397):

   content = zlib.decompress(content, zlib.MAX_WBITS)
   

   Similarly, zlib.decompress() returns the fully decompressed content as a single bytes object with no size bound.

3. Automatic invocation (line 1431): _decompressContent() is called automatically on every HTTP response that includes a Content-Encoding: gzip or deflate header. The full compressed body is already buffered in memory via response.read() before decompression begins.

Root cause: There is no max_decompressed_size, streaming decompression with size tracking, or decompression ratio check anywhere in the decompression path. The library unconditionally trusts the server's compressed payload size.

Attack vector: Any HTTP server (including man-in-the-middle attackers or compromised upstream services) can trigger this by returning a response with:

• Content-Encoding: gzip header
• A small compressed body that...