CVE-2026-84305 in sqlparse
Summary
by MITRE • 09/01/2026
sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, sqlparse.format(sql, reindent=True) and sqlformat --reindent route attacker-controlled parenthesized tuple lists through ReindentFilter._get_offset() in sqlparse/filters/reindent.py, where _flatten_up_to_token() repeatedly rebuilds and joins the statement prefix. Thousands of offset calculations walk an expanding token tree, producing quadratic CPU consumption for inputs that remain below MAX_GROUPING_TOKENS and causing request delays, reduced throughput, or worker starvation. This issue is fixed in version 0.6.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the sqlparse library represents a significant availability risk stemming from an inefficient algorithmic implementation within its SQL formatting utilities. Sqlparse serves as a widely adopted non-validating SQL parser for Python, frequently utilized by web frameworks and database management tools to parse, validate, and format SQL queries before execution or display. The specific flaw resides in the ReindentFilter component, which is responsible for reformatting SQL statements with proper indentation when invoked via methods such as sqlparse.format() with the reindent parameter set to true, or through the command-line interface using the --reindent flag. This functionality is critical for developers and automated systems that require human-readable output from raw SQL strings, but its implementation contains a performance-critical flaw that can be exploited by malicious actors.
The technical root cause of this vulnerability lies in how the ReindentFilter processes parenthesized tuple lists provided through attacker-controlled input. When such inputs are passed to the _get_offset() method within sqlparse/filters/reindent.py, the internal helper function _flatten_up_to_token() is triggered. This function operates by repeatedly rebuilding and joining the prefix of the SQL statement as it traverses a token tree that expands with each nested parenthesis or tuple element. Instead of using an efficient data structure to track offsets, such as maintaining cumulative sums in constant time, the implementation recalculates these values from scratch for every relevant token. This results in quadratic CPU consumption relative to the size and depth of the input string. The vulnerability is particularly insidious because it affects inputs that remain below the library's defined MAX_GROUPING_TOKENS limit, meaning standard validation checks designed to prevent excessive resource usage do not trigger, allowing deeply nested or numerous small tuples to cause disproportionate processing delays without being flagged as oversized payloads.
From an operational perspective, this inefficiency translates directly into a Denial of Service condition for any service relying on sqlparse for SQL formatting. Attackers can craft specific SQL strings containing carefully structured parenthesized tuple lists that force the parser to perform thousands of redundant offset calculations. This leads to severe request delays and reduced throughput in web applications or API services that format user-supplied SQL queries before processing them further. In environments with limited computational resources, such as serverless functions or containers with strict CPU limits, this can result in worker starvation where legitimate requests are queued behind the resource-hogging malicious query, effectively rendering the service unavailable to other users. The impact is not data leakage or unauthorized access but rather a degradation of system availability and responsiveness, which aligns closely with CWE-400: Uncontrolled Resource Consumption.
This vulnerability can be mapped to specific entries in industry-standard security frameworks that help categorize its nature and potential exploitation vectors. In the MITRE ATT&CK framework, this behavior corresponds to techniques related to resource exhaustion, specifically falling under tactics such as Impact or Defense Evasion depending on whether the goal is simply to disrupt service or to mask other malicious activities by consuming system resources. The underlying flaw is a classic example of an algorithmic complexity issue where input validation exists but fails to account for computational cost rather than just size limits. Recognizing this pattern allows security teams to identify similar vulnerabilities in other parsers that may use naive string manipulation techniques instead of optimized data structures like balanced trees or incremental parsing algorithms.
Mitigation strategies primarily involve upgrading the sqlparse library to version 0.6.0, where the developers have addressed this quadratic complexity issue by optimizing the offset calculation logic within the ReindentFilter. For organizations unable to immediately upgrade due to dependency constraints, alternative mitigation approaches include implementing strict input validation at the application layer before passing SQL strings to the parser. This can involve limiting the depth of nested parentheses or restricting the number of tuple elements in user-supplied queries. Additionally, deploying rate-limiting mechanisms on endpoints that trigger SQL formatting operations can help mitigate the impact by preventing a single attacker from monopolizing server resources through rapid-fire requests containing maliciously crafted payloads. Monitoring CPU usage spikes associated with sqlparse-related processes can also serve as an early detection mechanism for ongoing exploitation attempts in production environments.