CVE-2025-47287

What it actually does

The flaw is in Tornado's multipart/form-data request parser. When the parser encounters certain malformed multipart body conditions, it emits warning log entries but continues parsing the remaining request data instead of stopping early. A remote unauthenticated client that can send HTTP requests to an endpoint accepting multipart/form-data can repeatedly submit crafted malformed multipart bodies and cause the application to generate very large volumes of synchronous log output. Because the logging path is synchronous, excessive warning generation can block request handling, consume CPU and disk I/O, fill log storage, and degrade or deny service.

Why it matters to the business

Publicly reachable Tornado applications that accept file uploads or form submissions may be disrupted by relatively simple malformed HTTP requests. The main risk is availability loss: slow or failed application responses, saturated logging infrastructure, increased observability costs, disk exhaustion, noisy alerts, and potential cascading impact on services that depend on the affected application. This issue is not known to be in CISA KEV, has low EPSS, and has no reported public exploit maturity in the provided data, but the CVSS 7.5 availability impact warrants patching for internet-facing upload or form-processing services.

How an attack unfolds

An attacker first identifies a Tornado-powered endpoint that accepts multipart/form-data, commonly an upload or form submission route. The attacker sends malformed multipart requests designed to trigger parser warning paths repeatedly. Instead of rejecting the malformed request and stopping parsing immediately, vulnerable Tornado versions continue processing additional malformed parts and log warnings for each error encountered. By repeating these requests or embedding many malformed parts in request bodies, the attacker forces the application to perform synchronous logging at high volume. This can tie up application workers or the event loop, increase CPU and disk I/O, overwhelm log pipelines, and potentially fill disks, resulting in degraded performance or denial of service. No authentication, code execution, or data access is implied by the provided vulnerability details; the impact is availability-focused.

How to fix it

Upgrade Tornado to a version that includes the upstream fix. For source builds from tornadoweb/tornado Git, ensure the code includes commit ab5f35431242f95a5ef0a2ac228e54e89ab511f0 or a later commit. If consuming Tornado through a package manager, update to the first released package version that contains this fix or a newer supported release. As compensating controls until patching is complete, restrict access to upload/form endpoints where possible, enforce request body size limits, configure reverse proxies or WAFs to rate-limit malformed multipart requests, limit per-client request rates, ensure log rotation and disk quotas are enforced, and avoid synchronous high-volume warning logging where application architecture permits.

How to confirm the fix worked

Confirm the deployed Tornado dependency or source checkout includes commit ab5f35431242f95a5ef0a2ac228e54e89ab511f0 or a later fixed release. Review software bills of materials, lockfiles, container images, and runtime package inventories for Tornado versions or Git commits. In a staging environment, send malformed multipart/form-data requests to a representative endpoint and verify that parsing fails quickly without producing excessive repeated warning logs or causing measurable latency, CPU, or disk I/O spikes. Validate that upload endpoints have request-size limits, rate limits, and log rotation configured. For internet-facing services, scan exposed routes for multipart/form-data handlers and prioritize those for upgrade verification.

Typical attack path

1. Discover a Tornado-based web application endpoint that accepts multipart/form-data requests.
2. Send malformed multipart/form-data bodies that trigger parser warning conditions.
3. Include repeated malformed sections or send requests at volume to amplify warning generation.
4. Cause the vulnerable parser to continue processing and synchronously logging errors instead of failing fast.
5. Exhaust application, disk I/O, or logging pipeline capacity, resulting in slow responses, failed requests, or service outage.

How to detect it

Look for evidence of log-amplification behavior around endpoints that accept multipart/form-data. Useful sources include Tornado application logs, Python process logs, reverse proxy logs, web access logs, WAF logs, load balancer telemetry, container stdout/stderr, log aggregation metrics, disk utilization alerts, and APM traces. Investigate spikes in warning logs containing Tornado multipart parser messages, especially if correlated with repeated HTTP POST requests using Content-Type: multipart/form-data, malformed or missing boundary parameters, elevated 400/413/499/500 responses, increased request latency, or sudden disk/log pipeline saturation. Group events by source IP, user agent, URI path, and time window. Exploitation is more likely when a small set of clients generates disproportionate multipart parser warnings, many malformed POSTs, or repeated uploads that do not complete successfully. Because this is a denial-of-service issue, forensic evidence may be limited to logs and performance telemetry rather than persistent files or malware artifacts.

• Invalid multipart/form-data
• Invalid multipart/form-data: no final boundary
• multipart/form-data missing headers
• multipart/form-data value missing name
• Content-Type: multipart/form-data
• boundary=

What your security team should do

• Prioritize patching internet-facing Tornado applications that accept file uploads or multipart form submissions.
• Update Tornado to a release or source revision containing commit ab5f35431242f95a5ef0a2ac228e54e89ab511f0 or later.
• Inventory applications, containers, and build artifacts for Tornado usage, including transitive Python dependencies.
• Apply reverse proxy, load balancer, or WAF rate limits on multipart/form-data requests, especially requests with malformed boundaries or unusually high error rates.
• Set conservative maximum request body sizes and multipart upload limits for endpoints that do not require large uploads.
• Monitor warning-log volume, application latency, disk utilization, and log pipeline throughput for sudden spikes tied to multipart/form-data requests.
• Ensure log rotation, retention limits, and disk space alerts are in place so log amplification cannot exhaust storage.
• Create SIEM detections for bursts of Tornado multipart parser warnings from the same source IP, user agent, or endpoint.
• If suspicious activity is observed, preserve web access logs, application logs, reverse proxy logs, and relevant request metadata for incident review.