CVE-2026-103261 in Tornado
Summary
by MITRE • 10/01/2026
Tornado before 6.5.9 fails to limit the number of query string fields in HTTPServerRequest.__init__, allowing remote attackers to cause event-loop stalling by sending requests with thousands of query parameters. Attackers can send unauthenticated GET requests with unbounded query-string field counts to degrade response times for all clients sharing the same IOLoop.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability identified in Tornado versions prior to 6.5.9 represents a significant availability risk stemming from an absence of input validation regarding HTTP request parameters. Specifically, the HTTPServerRequest initialization process does not enforce any upper limit on the number of fields present within the query string portion of an incoming URL. This architectural oversight allows remote attackers to craft malicious GET requests containing thousands or even millions of distinct query parameter pairs. Because Tornado operates as a high-performance asynchronous web framework relying heavily on its internal IOLoop for handling concurrent connections, this lack of constraint directly impacts the core event loop mechanism responsible for processing network events and executing application logic.
From a technical perspective, the flaw lies in how the server parses and stores query string data during the request initialization phase. When an HTTPServerRequest object is instantiated, it typically iterates through all provided key-value pairs to populate its internal state. Without a cap on this iteration or storage process, the CPU cycles required to parse these excessive parameters accumulate rapidly. This computational overhead causes the event loop to stall, preventing it from processing other pending network events such as new connections, data reads, or writes for legitimate users. The result is a denial of service condition where response times degrade significantly across all clients sharing the same IOLoop instance, effectively rendering the application unresponsive until the malicious request completes its parsing cycle and control returns to the loop.
This vulnerability aligns with CWE-770: Allocation of Resources Without Limits or Throttling, as the system fails to restrict resource consumption based on input size. In terms of offensive security frameworks, this technique corresponds to ATT&CK T1498.002: Network Denial of Service via Resource Exhaustion by Application Layer Protocol Abuse. Attackers can exploit this flaw without authentication, making it particularly dangerous for public-facing services that accept GET requests with variable query strings. The impact is not limited to a single user session but affects the entire server instance or worker process handling the request, leading to widespread service degradation rather than isolated failures.
Mitigation strategies primarily involve upgrading Tornado to version 6.5.9 or later, where this limitation has been addressed by implementing strict caps on query string field counts. For environments unable to upgrade immediately, administrators should deploy a reverse proxy such as Nginx or Apache in front of the Tornado application to filter out requests with excessively long URLs or high numbers of parameters before they reach the backend server. Additionally, configuring web application firewalls to detect and block anomalous query string lengths can provide an additional layer of defense against this type of resource exhaustion attack.