CVE-2025-47287: Tornadoweb Tornado DoS Vulnerability

CVE-2025-47287 Overview

CVE-2025-47287 is a Denial of Service (DoS) vulnerability affecting Tornado, a widely-used Python web framework and asynchronous networking library. The vulnerability exists in Tornado's multipart/form-data parser, which continues processing data after encountering certain parsing errors while logging warnings for each error. This behavior allows remote attackers to craft malicious requests that generate an extremely high volume of log entries, effectively causing a denial of service condition. The impact is further amplified because Tornado's logging subsystem operates synchronously, meaning each log write blocks the event loop and degrades application performance.

Critical Impact

Remote attackers can exploit this vulnerability to cause service disruption through log flooding, with the synchronous logging mechanism amplifying the DoS impact on affected Tornado applications.

Affected Products

• Tornadoweb Tornado versions prior to 6.5.0
• Debian Linux 11.0

Discovery Timeline

• May 15, 2025 - CVE-2025-47287 published to NVD
• December 23, 2025 - Last updated in NVD database

Technical Details for CVE-2025-47287

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The flaw resides in the multipart/form-data request parser within Tornado's HTTP handling code. When the parser encounters malformed boundary markers or other parsing errors within multipart form data, it logs a warning message but then attempts to continue parsing the remaining data. An attacker can craft a request containing numerous intentional parsing errors, causing the parser to generate a warning log entry for each error encountered.

The severity of this DoS attack is compounded by a critical architectural characteristic: Tornado's logging subsystem is synchronous. In an asynchronous framework like Tornado, synchronous operations block the event loop, preventing other requests from being processed. When thousands of log entries are generated in rapid succession, the application becomes unresponsive as it spends the majority of its time writing log messages rather than handling legitimate requests.

Root Cause

The root cause lies in the error handling logic of the multipart form-data parser. Instead of terminating parsing when errors are detected, the parser logs warnings and continues processing. Combined with no rate limiting on log generation and the synchronous nature of Python's standard logging module, this creates a resource exhaustion vector. The vulnerable parser is enabled by default in all Tornado installations, making every application using Tornado's built-in form parsing potentially vulnerable.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker sends HTTP POST requests with Content-Type: multipart/form-data headers containing deliberately malformed multipart boundaries. Each malformed boundary triggers a logging operation, and the synchronous logging blocks Tornado's event loop. By sending requests with hundreds or thousands of malformed boundaries, an attacker can:

1. Exhaust disk space through excessive log file growth
2. Block the event loop, preventing legitimate request handling
3. Cause CPU exhaustion as the system processes log writes
4. Potentially trigger log rotation overhead if configured

The attack requires minimal bandwidth from the attacker's perspective while causing disproportionate resource consumption on the target server.

Detection Methods for CVE-2025-47287

Indicators of Compromise

• Unusually rapid growth in application log files, particularly warning-level entries related to multipart parsing
• High volume of HTTP POST requests with Content-Type: multipart/form-data from single or multiple IP addresses
• Increased disk I/O activity correlated with incoming HTTP traffic
• Application performance degradation or unresponsiveness during periods of normal-looking traffic volume

Detection Strategies

• Monitor log file growth rates and alert on anomalous increases, particularly in Tornado application logs
• Implement request rate limiting and monitor for violations, focusing on POST requests with multipart content types
• Configure web application firewalls (WAF) to detect and flag malformed multipart boundaries in request bodies
• Track response latency metrics to identify when synchronous logging is impacting application performance

Monitoring Recommendations

• Set up alerting on disk usage thresholds for partitions containing application logs
• Implement centralized log aggregation with anomaly detection for sudden spikes in warning-level log entries
• Monitor Tornado event loop latency metrics to detect blocking operations
• Track the ratio of multipart form requests to successful form submissions to identify attack patterns

How to Mitigate CVE-2025-47287

Immediate Actions Required

• Upgrade Tornado to version 6.5.0 or later, which contains the fix for this vulnerability
• If immediate upgrade is not possible, implement the proxy-based workaround to block malicious multipart requests
• Review and configure log rotation policies to prevent disk exhaustion during an active attack
• Consider implementing asynchronous logging handlers to reduce event loop blocking

Patch Information

The vulnerability has been addressed in Tornado version 6.5.0. The fix is available in commit b39b892bf78fe8fea01dd45199aa88307e7162f3. Users should upgrade to the patched version immediately. For Debian Linux 11.0 users, consult the Debian LTS Announcement for distribution-specific patching guidance. Additional details are available in the GitHub Security Advisory GHSA-7cx3-6m66-7c5m.

Workarounds

• Block requests with Content-Type: multipart/form-data at the reverse proxy or load balancer level if multipart form handling is not required by your application
• Implement rate limiting on POST requests at the proxy layer to reduce the impact of flooding attempts
• Configure log output to use asynchronous handlers (such as Python's QueueHandler) to minimize event loop blocking
• Restrict multipart form endpoints to authenticated users only to reduce the attack surface

# Nginx configuration to block multipart/form-data requests as a workaround
# Add this to your server or location block
if ($content_type ~* "multipart/form-data") {
    return 403;
}

# Alternative: Rate limit multipart requests
limit_req_zone $binary_remote_addr zone=multipart_limit:10m rate=10r/s;
location /upload {
    limit_req zone=multipart_limit burst=20 nodelay;
    proxy_pass http://tornado_backend;
}