What is the CVSS score of EUVD-2026-44505?

EUVD-2026-44505 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.7%.

Which versions of Tornado are affected by EUVD-2026-44505?

Tornado web framework versions prior to 6.5.6 contain a denial of service vulnerability allowing malicious HTTP servers to exhaust client memory through gzip decompression attacks, affecting…. A patch is available.

How to fix or mitigate EUVD-2026-44505?

Within 24 hours: Inventory all systems running Tornado and document current versions. Within 7 days: Disable gzip decompression in affected applications (set decompress_request=False for HTTPServer instances; disable response decompression for SimpleAsyncHTTPClient); implement strict response size limits at reverse proxy or load balancer layer (recommend <10MB threshold). Within 30 days: Monitor vendor security advisories for Tornado 6.5.6 patch release; establish upgrade readiness plan; validate all systems have mitigations enforced.

Tornado EUVD-2026-44505

| CVE-2026-49855 HIGH

Improper Handling of Highly Compressed Data (Data Amplification) (CWE-409)

2026-06-15 https://github.com/tornadoweb/tornado

GHSA-mgf9-4vpg-hj56 PYSEC-2026-3389

Information Disclosure

7.5

CVSS 3.1 · Vendor: https://github.com/tornadoweb/tornado

Severity by source

Vendor (https://github.com/tornadoweb/tornado) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

7.5 HIGH

Network-reachable malicious server, no privileges or interaction, low complexity; impact is memory exhaustion only, so C:N/I:N/A:H and no scope change.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/tornadoweb/tornado).

CVSS VectorVendor: https://github.com/tornadoweb/tornado

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 15, 2026 - 20:51 vuln.today

Analysis Generated

Jun 15, 2026 - 20:51 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

1 pypi packages depend on tornado (1 direct, 0 indirect)

Ecosystem-wide dependent count for version 6.5.6.

DescriptionCVE.org

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.

AnalysisAI

Denial of service in Tornado web framework versions prior to 6.5.6 allows a malicious HTTP server to exhaust client memory through a gzip decompression bomb against SimpleAsyncHTTPClient in its default configuration. The flaw stems from missing cumulative size enforcement on decompressed response bodies; HTTPServer is also vulnerable when explicitly configured with decompress_request=True. No public exploit identified at time of analysis, though the technique (gzip bomb) is well-understood and trivial to weaponize.

Technical ContextAI

Tornado is a widely-used Python asynchronous networking library and web framework (pkg:pip/tornado) that ships SimpleAsyncHTTPClient for outbound HTTP and HTTPServer for inbound requests. The root cause maps to CWE-409 (Improper Handling of Highly Compressed Data, a.k.a. data amplification / decompression bomb): the gzip routines decompress in bounded chunks and enforce max_body_size against the compressed byte stream, but never tally the cumulative decompressed output. A small, high-ratio gzip stream (megabytes compressed expanding to gigabytes) therefore bypasses the existing limit. The fix in 6.5.6 extends max_body_size enforcement to both the compressed and the cumulative decompressed total.

RemediationAI

Upstream fix available: upgrade to Tornado 6.5.6, where max_body_size is now enforced against both the compressed and the cumulative decompressed response size (vendor advisory: https://github.com/tornadoweb/tornado/security/advisories/GHSA-mgf9-4vpg-hj56). If an immediate upgrade is not possible, mitigate on the client side by setting decompress_response=False on SimpleAsyncHTTPClient - the trade-off is that callers receive raw gzip bytes and must decompress themselves with their own size cap - or switch to CurlAsyncHTTPClient, which relies on libcurl's decompression and is not affected (trade-off: an additional libcurl/pycurl runtime dependency and slightly different behavior/options). On the server side, leave decompress_request at its default (False) until patched, accepting that gzip-encoded request bodies will not be transparently decompressed.