CVE-2026-59939

What it actually does

CVE-2026-59939 is an uncontrolled resource consumption flaw in the Python httplib2 HTTP client library before version 0.32.0. When httplib2 receives an HTTP response with Content-Encoding: gzip or Content-Encoding: deflate, it decompresses the response body without enforcing a maximum decompressed size. A malicious or compromised HTTP server can return a very small compressed payload that expands to a very large object in memory, causing the client process to raise MemoryError, become unresponsive, or be terminated by the operating system out-of-memory killer. The impact is availability-only: confidentiality and integrity are not directly affected, but any application, worker, job, agent, or service using vulnerable httplib2 to fetch attacker-controlled or compromised URLs can be crashed remotely without authentication.

Why it matters to the business

Applications that depend on vulnerable versions of httplib2 can be remotely crashed by a malicious HTTP response, potentially interrupting background jobs, API integrations, automation workflows, data ingestion pipelines, monitoring agents, or user-facing services. The CVSS score is high for availability impact, and exploit code is reported as available, increasing practical risk. EPSS is currently low and the issue is not in the CISA Known Exploited Vulnerabilities catalog, but organizations with Python services that contact third-party, user-supplied, or less-trusted URLs should treat this as higher priority because exploitation only requires the client to make an HTTP request to a hostile or compromised server.

How an attack unfolds

An attacker first identifies or influences a Python application that uses httplib2 before 0.32.0 to retrieve HTTP or HTTPS content. The attacker may operate a malicious server, compromise a legitimate upstream endpoint, poison a redirect target, or provide a URL that the application later fetches. When the vulnerable client sends a request, the attacker responds with headers indicating Content-Encoding: gzip or deflate and a compressed body crafted as a decompression bomb: small on the wire but extremely large once expanded. httplib2 accepts the encoded response and calls its decompression routine without bounding the output size. Memory use rapidly increases until Python raises MemoryError or the operating system terminates the process due to out-of-memory conditions. The attacker can repeat the request/response cycle to keep workers or services unavailable, especially where supervisors automatically restart crashed processes.

How to fix it

Upgrade httplib2 to version 0.32.0 or later wherever it is installed directly or transitively. Rebuild and redeploy Python applications, containers, virtual environments, serverless packages, and CI/CD artifacts that vendor or pin vulnerable httplib2 versions. If immediate upgrade is not possible, reduce exposure by avoiding httplib2 requests to user-controlled or untrusted URLs, disabling automatic response decompression where feasible, enforcing strict response size limits at application boundaries, applying time and memory limits to worker processes, and isolating outbound fetch functionality from critical services. Consider using dependency lockfile updates and software composition analysis to locate both direct and transitive httplib2 usage.

How to confirm the fix worked

Confirm that all runtime environments report httplib2 version 0.32.0 or later, for example with `python -m pip show httplib2`, `pip freeze`, `pipdeptree`, Poetry/Pipenv lockfiles, container image scans, and SBOM/dependency inventory tools. Validate deployed artifacts rather than only source repositories, because packaged applications may include vendored dependencies or stale virtual environments. Where safe and authorized, test representative non-production services with a controlled compressed response that has a bounded but oversized decompressed body and verify that the process no longer consumes unbounded memory or crashes. Confirm that application-level response size limits, memory limits, and restart policies behave as expected.

Typical attack path

1. Identify an application, service, job, agent, or integration that uses Python httplib2 before version 0.32.0 for outbound HTTP requests.
2. Find a way to make that client request attacker-controlled or compromised HTTP content, such as through a user-supplied URL, webhook destination, feed, API endpoint, redirect, or third-party integration.
3. Serve an HTTP response with Content-Encoding: gzip or Content-Encoding: deflate.
4. Return a small compressed payload that expands to an extremely large decompressed body.
5. Allow httplib2 to process the response and perform unbounded decompression in memory.
6. Cause the client process to raise MemoryError, hang, or be killed by the operating system OOM killer.
7. Repeat requests or wait for automatic retries/restarts to sustain denial of service.

How to detect it

To determine whether exploitation already occurred, review application logs, process supervisor logs, container orchestration events, kernel logs, and endpoint telemetry for abrupt Python process exits, MemoryError exceptions, OOM-kill events, or repeated worker restarts around outbound HTTP requests. Correlate crashes with HTTP client telemetry, proxy logs, egress firewall logs, packet captures, or APM traces showing responses from external servers using Content-Encoding: gzip or Content-Encoding: deflate, especially where the compressed response size was small but memory usage spiked sharply. Look for repeated failures when contacting the same domain, URL, redirect destination, feed, webhook, or third-party API. In Python stack traces, prioritize events referencing httplib2 decompression code or `_decompressContent`. Because this vulnerability is a denial-of-service condition rather than a code execution flaw, forensic artifacts are most likely to be crash logs, memory pressure events, restart loops, and anomalous compressed responses rather than persistent files or registry changes.

• MemoryError
• _decompressContent
• httplib2/__init__.py
• httplib2/init.py
• Content-Encoding: gzip
• Content-Encoding: deflate
• Out of memory: Killed process
• oom-kill
• OOMKilled
• Killed process python
• signal 9
• SIGKILL

What your security team should do

• Inventory Python applications, containers, functions, automation jobs, and packaged tools that include httplib2 before 0.32.0.
• Prioritize remediation for systems that fetch external, third-party, user-supplied, redirect-following, or otherwise untrusted URLs.
• Upgrade httplib2 to 0.32.0 or later and redeploy affected workloads from clean builds.
• Add dependency scanning gates to prevent reintroduction of httplib2 versions earlier than 0.32.0.
• Review outbound HTTP-fetching features for response size limits, decompression limits, timeout controls, and retry behavior.
• Harden service supervisors and container limits so repeated OOM crashes do not cascade into broader service instability.
• Search recent logs and telemetry for Python MemoryError events, OOM kills, abrupt worker restarts, and requests immediately preceding responses with gzip or deflate content encoding.
• Monitor for repeated crashes tied to the same external domains, URLs, IP addresses, redirects, feeds, webhooks, or integration endpoints.