CVE-2026-49855: 
Python vulnerability analysis and mitigation

CVE-2026-49855 is a gzip bomb (data amplification) vulnerability in the Tornado Python web framework and asynchronous networking library, classified as "Improper Handling of Highly Compressed Data" (CWE-409). Prior to version 6.5.6, Tornado's gzip decompression routines processed data in limited-size chunks but imposed no overall limit on the total accumulated decompressed data, enabling a malicious server to exhaust the memory of any client using SimpleAsyncHTTPClient in its default configuration, or any HTTPServer configured with decompress_request=True. The vulnerability was reported by researcher yuui25, published to the GitHub Advisory Database on June 15, 2026, and assigned a CVSS v3.1 base score of 7.5 (High) (Github Advisory). Affected versions are all Tornado releases prior to 6.5.6 (Github Advisory).

The root cause is CWE-409 (Improper Handling of Highly Compressed Data / Data Amplification): Tornado's _GzipMessageDelegate class in http1connection.py tracked and limited the size of individual compressed chunks but never tracked the cumulative total of decompressed output (Tornado Commit). An attacker controlling a server can respond with a specially crafted gzip-compressed HTTP response (a "gzip bomb") that decompresses to an arbitrarily large payload; the Tornado client will continue decompressing and buffering chunks until system memory is exhausted. The attack requires no authentication and no user interaction — only that the vulnerable Tornado application makes an outbound HTTP request to an attacker-controlled server via SimpleAsyncHTTPClient, or that HTTPServer is configured with decompress_request=True (Github Advisory). The fix adds a _decompressed_body_size counter to _GzipMessageDelegate and raises httputil.HTTPInputError when the cumulative decompressed size exceeds max_body_size (Tornado Commit).

Successful exploitation results in unbounded memory consumption on the Tornado process, leading to denial of service (DoS) through memory exhaustion or process crash. There is no impact on confidentiality or data integrity — the vulnerability is purely an availability issue. Applications using SimpleAsyncHTTPClient to fetch content from untrusted or attacker-controlled servers are at highest risk, as are servers with decompress_request=True that accept gzip-compressed request bodies from untrusted clients (Github Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the available data. The NVD SSVC assessment indicates exploitation status as "none" and the attack is classified as "automatable" due to its network-accessible, no-authentication-required nature (Github Advisory). The EPSS score is approximately 0.052% (Feedly data) to 0.572% (GitHub Advisory), placing it in the lower-to-mid range of exploitation likelihood. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Set up a malicious server: Configure an HTTP server that responds to requests with a gzip-compressed body containing a "gzip bomb" — a highly compressed payload that expands to gigabytes of data upon decompression (e.g., a large block of repeated bytes compressed with maximum gzip compression).
2. Identify a vulnerable target: Find a Tornado application (version < 6.5.6) that makes outbound HTTP requests via SimpleAsyncHTTPClient to attacker-controlled or attacker-influenced URLs, or an HTTPServer configured with decompress_request=True.
3. Trigger the request: Cause the vulnerable Tornado application to send an HTTP GET (or POST) request to the malicious server — for example, by submitting a URL to a web scraping endpoint, exploiting an SSRF condition, or sending a gzip-compressed request body to the target HTTPServer.
4. Deliver the gzip bomb response: The malicious server responds with Content-Encoding: gzip and the crafted payload. Tornado's _GzipMessageDelegate begins decompressing chunks without enforcing a cumulative size limit.
5. Exhaust memory: The Tornado process continuously decompresses and buffers data until system memory is exhausted, causing the process to crash or become unresponsive, resulting in denial of service (Github Advisory, Tornado Commit).

• Logs: Tornado application logs showing httputil.HTTPInputError: decompressed body too large (present only in patched version 6.5.6+); absence of this error in older versions despite large response processing may indicate exploitation.
• Process/System: Rapid, sustained increase in memory usage of the Tornado Python process (python/python3) without a corresponding increase in legitimate traffic load; OOM (Out of Memory) killer events in system logs (/var/log/syslog, dmesg) referencing the Tornado process.
• Network: Outbound HTTP connections from the Tornado application to unexpected or newly observed external hosts returning responses with Content-Encoding: gzip and unusually small Content-Length values relative to the time taken to process the response.

Upgrade Tornado to version 6.5.6 or later, which enforces max_body_size on the cumulative decompressed body size in _GzipMessageDelegate (Github Advisory, Tornado Commit). If immediate upgrade is not possible, apply one of the following workarounds:

• For SimpleAsyncHTTPClient users: set decompress_response=False in the HTTP client configuration to disable automatic gzip decompression.
• Alternatively, switch to CurlAsyncHTTPClient, which is not affected by this issue.
• For HTTPServer users: avoid setting decompress_request=True unless strictly necessary, or upgrade promptly (Github Advisory).

SUSE has also released updated packages for affected distributions (SUSE Advisory).

The vulnerability received coverage from security news outlets including SecurityOnline.info and Linux security aggregators, as well as distribution-level advisories from SUSE and openSUSE (openSUSE Advisory). The OpenHands project (an AI coding assistant that depends on Tornado) addressed the vulnerability in its cloud-1.39.0 and 1.9.0 releases. No significant controversy or notable researcher commentary beyond the standard advisory process has been observed.