CVE-2025-67726

What it actually does

The flaw is an algorithmic complexity denial-of-service issue in Tornado's multipart/form-data request parsing. A crafted multipart request with many parameters or specially structured form parts can trigger quadratic-time processing, causing a Tornado worker or event loop to spend disproportionate CPU time parsing a single request. Because Tornado applications often rely on event-loop concurrency, CPU exhaustion in request parsing can delay or block handling of unrelated legitimate requests. The impact is availability degradation; the vulnerability does not by itself provide code execution, data disclosure, or privilege escalation.

Why it matters to the business

Internet-facing or high-traffic applications built on vulnerable Tornado code can be slowed or made unavailable by relatively low-cost HTTP traffic. The CVSS score is high for availability impact, but the current EPSS is low, it is not in CISA KEV, and no public exploit maturity is reported, so remediation should be prioritized for exposed services and critical APIs rather than treated as an active mass-exploitation emergency. Operational consequences may include customer-facing outages, failed transactions, degraded API latency, autoscaling cost spikes, alert fatigue, and resource contention with other services.

How an attack unfolds

An attacker first identifies an HTTP endpoint served by a vulnerable Tornado application that accepts multipart/form-data, commonly file upload, form submission, API import, or webhook-style endpoints. The attacker then sends crafted POST requests containing an unusually large number of multipart parameters or form parts designed to trigger inefficient parsing behavior. The vulnerable parser performs work that grows quadratically with the number or structure of supplied parameters, consuming excessive CPU before the application handler can reject or process the request. Repeating these requests, potentially from a small number of clients, can saturate Tornado worker processes or the Python event loop, producing high latency, request timeouts, and 5xx responses for legitimate users.

How to fix it

Upgrade Tornado to a version or source revision that includes the fix. For the Git-tracked affected product, ensure the deployed code contains commit 38014ddb51520ff7762c1d55535925dba2cdbe31 or a later release that incorporates it. Rebuild and redeploy all applications and containers that vendor or pin Tornado. If immediate upgrade is not possible, apply compensating controls: enforce maximum request body size, maximum multipart part count, maximum field count, and upload limits at the reverse proxy, load balancer, WAF, and application layers; rate-limit multipart POST requests per source and per route; restrict upload/form endpoints to authenticated users where feasible; set conservative request timeouts; and isolate or horizontally scale upload-handling workers to reduce blast radius.

How to confirm the fix worked

Confirm dependency state by checking package metadata, lockfiles, container images, SBOMs, and vendored source for Tornado versions or commits; for source deployments, verify that commit 38014ddb51520ff7762c1d55535925dba2cdbe31 or later is present. In running environments, confirm the effective Tornado package loaded by the application rather than only the repository declaration. Validate edge controls by sending benign multipart requests that exceed configured field, part, or body-size limits and confirming they are rejected early with expected 4xx responses. In a non-production environment, compare CPU and latency behavior before and after patching using controlled multipart requests with increasing part counts; patched or mitigated systems should reject excessive requests or show bounded, non-quadratic parsing behavior. Monitor after deployment for reduced request_time/upstream_response_time spikes and absence of CPU saturation during multipart traffic bursts.

Typical attack path

1. Reconnaissance identifies Tornado-backed HTTP services and endpoints that accept multipart/form-data requests.
2. The attacker selects endpoints likely to invoke Tornado request body parsing, such as upload or form submission routes.
3. The attacker sends crafted multipart/form-data POST requests containing many form-data parts, repeated parameter names, or unusually large parameter sets.
4. Tornado spends excessive CPU time parsing the multipart body before application-level logic can complete.
5. One or more worker processes or event loops become CPU-bound, increasing latency and error rates.
6. The attacker repeats or distributes the requests to maintain service degradation or denial of service.

How to detect it

Look for evidence of availability-focused abuse rather than compromise artifacts. Useful sources include reverse-proxy and load-balancer access logs, WAF logs, application access logs, APM traces, Tornado application logs, container or host CPU metrics, process-level telemetry, and packet captures if available. Hunt for bursts of POST requests with Content-Type multipart/form-data, especially to upload or form endpoints, where request latency, upstream response time, or application CPU increases sharply without a corresponding increase in successful business activity. Indicators include repeated requests from the same source or small set of sources, unusually large counts of multipart boundaries or Content-Disposition form-data headers per request, many repeated field names, elevated 499/500/502/503/504 responses, client disconnects, request timeouts, and Tornado worker processes pinned at high CPU. Because this is a denial-of-service condition, successful exploitation may leave no files, persistence, registry keys, or payload execution artifacts. If threat hunting historical data, correlate multipart POST spikes with CPU saturation, event-loop lag, autoscaling events, degraded SLOs, and error-rate alerts.

• Content-Type: multipart/form-data
• multipart/form-data; boundary=
• Content-Disposition: form-data
• POST requests with multipart/form-data and unusually high request_time
• POST requests with multipart/form-data and unusually high upstream_response_time
• Repeated multipart/form-data POST requests returning 500
• Repeated multipart/form-data POST requests returning 502
• Repeated multipart/form-data POST requests returning 503
• Repeated multipart/form-data POST requests returning 504
• Repeated multipart/form-data POST requests returning 499
• High frequency of multipart boundary markers in a single HTTP request body
• Many repeated Content-Disposition: form-data headers in a single HTTP request body
• Many repeated multipart form field names in a single HTTP request body
• Tornado worker process sustained near 100% CPU during multipart POST traffic
• python process sustained near 100% CPU during multipart POST traffic

What your security team should do

• Inventory all applications, containers, serverless packages, and vendored dependencies that use Tornado, prioritizing internet-facing services and endpoints accepting multipart/form-data.
• Patch or rebuild affected deployments so they include Tornado commit 38014ddb51520ff7762c1d55535925dba2cdbe31 or a later fixed release.
• Apply defense-in-depth limits at the proxy/WAF/application layers for multipart body size, number of parts, number of form fields, request duration, and per-client request rate.
• Add monitoring and alerting for spikes in multipart POST volume, high CPU in Tornado workers, elevated request latency, 499/500/502/503/504 responses, and upload endpoint saturation.
• Review upload and form endpoints for unnecessary unauthenticated access and restrict them where business requirements allow.
• Ensure autoscaling policies do not mask the attack indefinitely by creating uncontrolled cost growth; pair scaling with rate limiting and request validation.
• Retain HTTP access logs, WAF logs, reverse-proxy logs, application logs, and CPU/process telemetry long enough to investigate possible pre-patch exploitation.