CVE-2026-31958: 
Python vulnerability analysis and mitigation

CVE-2026-31958 is a denial-of-service vulnerability in the Tornado Python web framework and asynchronous networking library, caused by unbounded multipart/form-data parsing. In versions prior to 6.5.5, the only limit on the number of parts in a multipart request body is the max_body_size setting (default 100MB), and parsing occurs synchronously on the main thread, allowing an unauthenticated remote attacker to exhaust CPU resources. The vulnerability was published on March 10–11, 2026, and affects all Tornado versions up to and including 6.5.4. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). Tornado's multipart/form-data parser imposes no limit on the number of individual parts within a request body — only on the total body size — and performs all parsing synchronously on the event loop's main thread. An attacker can craft a single HTTP POST request with Content-Type: multipart/form-data containing an extremely large number of small parts that collectively stay within the 100MB body limit, forcing the server to spend significant CPU time parsing them and blocking all other request handling. No authentication or special privileges are required; the attack surface is any Tornado endpoint that accepts multipart form data (GitHub Advisory, GitHub Advisory).

Successful exploitation causes the Tornado application to become unresponsive or completely unavailable due to CPU exhaustion on the main thread, resulting in a high availability impact with no confidentiality or integrity impact. Because Tornado's event loop is single-threaded, a single malicious request can block all concurrent request processing, effectively taking the service offline for legitimate users. Downstream products embedding vulnerable Tornado versions — including IBM Maximo Application Suite, IBM API Connect, IBM Observability with Instana (OnPrem), IBM Db2 on Cloud Pak for Data, and Cloudera Data Platform Private Cloud Base — are also affected (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.028–0.048%, indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Despite the low exploitation evidence, the attack requires no authentication, no user interaction, and low complexity, making it straightforward to attempt against any exposed Tornado endpoint that processes multipart form data.

1. Reconnaissance: Identify internet-facing services running Tornado versions ≤ 6.5.4 using tools like Shodan, Censys, or by inspecting HTTP response headers (e.g., Server: TornadoServer/x.x.x) or application fingerprinting.
2. Identify a multipart-accepting endpoint: Locate an HTTP POST endpoint on the target application that accepts multipart/form-data requests (e.g., file upload forms, API endpoints).
3. Craft a malicious multipart request: Construct an HTTP POST request with Content-Type: multipart/form-data containing a very large number of small parts (e.g., thousands of minimal boundary-separated parts) that collectively remain within the 100MB max_body_size limit.
4. Send the request: Transmit the crafted request to the target endpoint using tools such as curl, Python's requests library, or a custom script. The server's main thread will begin synchronous parsing of all parts.
5. Achieve denial of service: The synchronous parsing blocks Tornado's event loop, preventing it from handling any other requests. Repeating or sustaining this attack causes prolonged or complete service unavailability (GitHub Advisory).

• Network: Unusually large HTTP POST requests with Content-Type: multipart/form-data to application endpoints; requests approaching the configured max_body_size limit (default 100MB) from a single source IP.
• Logs: Tornado access logs showing repeated large POST requests to the same endpoint; application logs indicating slow or stalled request processing; absence of responses to concurrent legitimate requests during the attack window.
• Process: Tornado worker process showing sustained high CPU utilization (near 100%) on a single core without a corresponding increase in request throughput; event loop latency metrics spiking significantly.
• Application Behavior: Legitimate users experiencing timeouts or connection refusals coinciding with receipt of large multipart requests.

The primary remediation is to upgrade Tornado to version 6.5.5 or later, which introduces a default limit of 100 parts per multipart request and new configurable controls via tornado.httputil.ParseMultipartConfig (GitHub Advisory). If multipart/form-data parsing is not required by the application, it can now be disabled entirely in 6.5.5. As interim mitigations prior to patching, operators should implement network-level rate limiting and request size throttling (e.g., via a reverse proxy such as nginx or HAProxy) to restrict oversized or high-frequency multipart requests. Red Hat has issued multiple errata addressing this vulnerability across RHEL 7–10 (RHSA-2026:8093, RHSA-2026:11454, RHSA-2026:13641, RHSA-2026:13670, and others); IBM has also released patches for affected products including Maximo Application Suite, API Connect, Instana, and Db2 on Cloud Pak for Data (Red Hat Bugzilla).

The vulnerability was reported by security researchers identified as 0x-Apollyon and bekkaze, and the advisory was published by Tornado maintainer bdarnell on March 10, 2026 (GitHub Advisory). The issue received coverage in Linux security news outlets and distribution security announcements (Debian LTS, openSUSE, Ubuntu USN-8198-1/2, Amazon Linux, Rocky Linux, AlmaLinux), reflecting broad ecosystem impact. No significant controversy or notable social media discussion beyond routine vulnerability tracking has been observed.