Answer in brief
CVE-2026-49855 records a High severity (CVSS 7.5) vulnerability in tornado AsyncHTTPClient accumulates decompressed chunks without size limit (gzip bomb). The current sources do not mark it as known exploited. The current feed maps tornado (pip), tornado (pypi). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps tornado (pip), tornado (pypi). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| tornadopip | <6.5.6 | 6.5.6 |
| tornadopypi | >=0 <6.5.6 | 6.5.6 |
Published upstream
Jun 15, 2026
Evidence: source:osv:source_dates:source-dates:recordSource modified
Sep 10, 2026
Evidence: source:osv:source_dates:source-dates:recordFirst seen by HOL
Jun 19, 2026
Tornado's gzip decompression routines work in limited-size chunks, but have no overall limit for the total size of decompressed chunks that they will accumulate (There has always been a limit for the total *compressed* size). This allows a malicious server to consume effectively unlimited amounts of memory if it is accessed via SimpleAsyncHTTPClient in its default configuration. `HTTPServer` is not affected in its default configuration, but it is if `decompress_request=True` is set. This bug is fixed in Tornado 6.5.6. `max_body_size` is now checked both for the compressed and cumulative decompressed size of the response. Prior to upgrading, this issue can be mitigated by setting `decompress_response=False` or using `CurlAsyncHTTPClient`.
Quoted source text, attributed separately from HOL analysis.