CVE-2026-91990 in Tornado
Summary
by MITRE • 09/15/2026
Tornado before 6.5.8 contains a memory amplification vulnerability in parse_multipart_form_data that splits multipart data before validating the max_parts limit. Attackers can send crafted multipart requests with many parts to create large transient lists, exhausting server memory and causing denial of service.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The Tornado web framework prior to version 6.5.8 contains a critical resource exhaustion vulnerability within its HTTP request parsing logic, specifically in the parse_multipart_form_data function. This flaw stems from an improper ordering of operations during the processing of multipart/form-data requests. When a client sends a POST request with multiple file uploads or form fields encoded as multipart data, Tornado is designed to limit the number of parts processed to prevent abuse and manage resource usage effectively. However, in versions before 6.5.8, the framework splits the incoming multipart payload into individual components and constructs large transient lists representing these parts before it checks whether the total count exceeds the configured max_parts threshold. This architectural oversight means that even if a request is intended to be rejected due to exceeding part limits, the server must first allocate memory for all parsed segments in RAM.
This behavior creates a significant denial of service vector known as resource amplification or memory exhaustion. An attacker can exploit this by sending crafted multipart requests containing an extremely large number of parts, potentially numbering in the thousands or millions depending on system constraints. Because each part requires memory allocation for its headers and body data during the splitting phase, the server's memory footprint grows rapidly proportional to the number of parts sent. Since the validation occurs after the split operation, the application consumes substantial amounts of RAM before it can determine that the request is invalid. This leads to rapid depletion of available heap space on the web server or reverse proxy running Tornado, potentially causing the process to crash via an out-of-memory error or triggering operating-level memory pressure mechanisms such as the Linux Out-Of-Memory killer.
The operational impact of this vulnerability extends beyond simple application crashes. In production environments where multiple services share resources or run within containerized deployments with strict memory limits, a single malicious request can destabilize not only the Tornado process but also adjacent containers or host system stability. This results in service unavailability for legitimate users and requires manual intervention to restart affected processes unless automated recovery mechanisms are in place. Furthermore, if the server is part of a larger cluster behind a load balancer, repeated exploitation attempts could trigger health check failures leading to nodes being removed from rotation, thereby reducing overall capacity and availability. The vulnerability aligns with CWE-789: Memory Allocation with Excessive Size or Count, as it involves allocating memory based on untrusted input without sufficient prior validation of size constraints relative to system capabilities.
From a threat intelligence perspective, this flaw facilitates Denial of Service attacks categorized under MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically through resource exhaustion via application layer abuse. Attackers do not need authentication or complex exploit chains; they merely need the ability to send HTTP POST requests with multipart content types. This simplicity makes it a low-effort, high-impact vector for disrupting services that rely on file uploads or multi-part form submissions, such as user profile updates, document management systems, or API endpoints accepting structured data payloads.
To mitigate this vulnerability, organizations running Tornado must upgrade to version 6.5.8 or later immediately. The fix ensures that the max_parts limit is validated before any significant memory allocation occurs for splitting the multipart stream. For environments where upgrading is not instantly feasible, temporary mitigations include configuring reverse proxies like Nginx or Apache to enforce strict limits on the number of parts in incoming requests and dropping those that exceed thresholds. Additionally, setting appropriate timeout values and connection limits can help reduce the window of exposure during an attack. Monitoring server memory usage for anomalous spikes correlated with high volumes of multipart POST requests can also aid in early detection of exploitation attempts while patching efforts are underway.