CVE-2026-82397

What it actually does

Tornado parses application/x-www-form-urlencoded bodies with urllib.parse.parse_qs without a max_num_fields cap. Body parsing runs synchronously on the single-threaded IOLoop in HTTPServerRequest._parse_body / parse_body_arguments before any handler (and thus before app-level auth). A request packed with an extreme number of delimiter-separated fields, sized up to the default 100 MiB max_buffer_size, can stall the event loop and delay every connection on that process. Confidentiality and integrity are unaffected; availability of the worker is fully impacted.

Why it matters to the business

Unauthenticated callers can freeze Tornado-based APIs and sites so legitimate users see timeouts and errors, driving outages, SLA breaches, and incident cost. Any internet-facing service still on Tornado before 6.5.8 is exposed. The issue is not in CISA KEV, has no reported in-the-wild use, and exploit maturity is none, but it has been public for about a month, needs no credentials, and is cheap to retry—treat production internet-facing instances as urgent to patch.

How an attack unfolds

A remote, unauthenticated attacker sends HTTP requests with Content-Type application/x-www-form-urlencoded whose bodies contain a very large number of form fields, up to the server body buffer limit. Tornado parses that body on the event loop before dispatching a handler, so application authentication and most handler rate limits never run. parse_qs then burns CPU until parsing finishes, during which the process cannot service other connections. Repeating such requests after each parse keeps workers unavailable. No named threat actors or ransomware campaigns are associated with this CVE.

How to fix it

Upgrade Tornado to 6.5.8 or later, which limits fields passed to parse_qs. Rebuild lockfiles, containers, and images so transitive dependencies do not keep a vulnerable tornado package. If you cannot upgrade immediately, lower HTTPServer max_buffer_size, and at a reverse proxy or WAF reject oversized application/x-www-form-urlencoded bodies and cap form field counts. Do not expose Tornado directly to untrusted networks.

How to confirm the fix worked

Confirm installed tornado is 6.5.8 or newer via package metadata, lockfiles, and SBOMs (pip/poetry/pipenv). Search inventories for tornado<6.5.8. After upgrade, exercise normal form POSTs while watching concurrent health checks and event-loop latency; the service should stay responsive. Review HTTPServer construction for an overly large max_buffer_size. Do not use production-scale field-flood requests as a test.

Typical attack path

1. Find a network-reachable Tornado HTTP service that accepts request bodies.
2. Send unauthenticated requests with Content-Type application/x-www-form-urlencoded and a body engineered for an extremely high field count within max_buffer_size.
3. Parsing blocks the process event loop before handler dispatch, causing timeouts and stalled connections for other clients.
4. Resubmit similar requests to prolong denial of service across workers.

How to detect it

This is in-memory resource exhaustion, not malware, so there are typically no dropped files or persistence artifacts. Hunt time windows of event-loop blockage or pegged CPU coinciding with inbound POST/PUT/PATCH requests whose Content-Type is application/x-www-form-urlencoded and whose bodies are unusually large or contain an extreme number of field separators. Access and reverse-proxy logs (timeouts, 499/504, upstream reset) from a small set of sources sending large form bodies are the main historical signal. During an outage, process samples or py-spy/faulthandler dumps showing parse_qs, tornado/escape.py, or tornado/httputil.py parse_body_arguments indicate this path. No KEV listing, ransomware use, or named actors are documented for this issue.

• Content-Type: application/x-www-form-urlencoded
• Content-Length: 104857600
• tornado/httputil.py
• parse_body_arguments
• tornado/escape.py
• tornado/web.py
• RequestHandler._execute
• urllib.parse.parse_qs

What your security team should do

• Inventory Python services and images depending on Tornado and flag versions older than 6.5.8.
• Patch internet-facing instances to Tornado 6.5.8 or later first, then internal services.
• Until patched, enforce proxy/WAF body-size and form-field limits and consider reducing max_buffer_size.
• Rebuild and redeploy so lockfiles and base images do not reintroduce a vulnerable Tornado.
• Watch event-loop lag, worker CPU in parse/url-decode paths, and large form-urlencoded POSTs for residual exposure.