Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When SQL is formatted with reindentation enabled, ReindentFilter repeatedly rebuilds prefixes of the current statement to calculate token offsets. An attacker who controls SQL sent to this opt-in formatting path can supply a parenthesized tuple list that remains just below the grouping-token cap. Thousands of offset calculations then traverse an expanding token tree, causing multi-second CPU consumption from an input of roughly 16 KB and degrading service availability. Details ReindentFilter.getoffset() joins the tokens returned by flattenuptotoken() to calculate the current output position. Each call begins by flattening the current statement from its start and walks until the target token. Tuple-list reindentation invokes this calculation repeatedly as it processes many parenthesized values, so later calls redo an increasingly large amount of prior work. The vulnerable path is reached through sqlparse.format(sql, reindent=True) and sqlformat --reindent. A carefully sized…
Recommended action: Upgrade to 0.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at sqlparse/keywords.py:33 uses a backreference (\1) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required. Scope note: the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see "Additional affected pattern: multiline comments" below. Details The vulnerable regex is defined in sqlparse/keywords.py as part of SQLREGEX: This pattern first captures a…
Recommended action: Upgrade to 0.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
sqlparse ships hard limits (MAXGROUPINGDEPTH=100, MAXGROUPINGTOKENS=10000) intended to bound parsing work on attacker-supplied SQL, but the path that reaches those limits is itself O(ndepth) per token-group construction. A ~1-2 KB SQL payload (e.g. SELECT (((((1))))) ... with 500-2000 nesting levels, or a 200-400-level nested CASE WHEN chain) drives the parser to spend multiple seconds of CPU before the depth cap raises SQLParseError. Concretely: a 2 KB malicious payload consumes ~10 seconds of CPU per request on a single worker (~5000x CPU-to-input amplification), while a benign 1 KB SQL completes in ~3 ms. The root cause is TokenList.init calling super().init(None, str(self)). TokenList.str flattens the entire subtree on every call, and grouping constructs a new TokenList for every parenthesis / CASE / list group, so a tree of depth d with n total tokens performs O(nd) flatten work just to materialize the cached value field, which is then never read for grouped nodes (they…
Recommended action: Upgrade to 0.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A comment-only statement (-- c\nn) may cause a Denial of Service (DoS). Details Location: sqlparse/engine/grouping.py:331-341 (groupcomments), invoked first in group() at grouping.py:439. Reachable via sqlparse.parse() and sqlparse.format(sql, stripcomments=True). A statement made of many single-line comments ('-- c\n' repeated) lexes in O(n) but groupcomments is O(n²): The while loop runs n times and each tokennextby / tokennotmatching rescans the O(n) remaining tokens. When all tokens are comments/newlines nothing ever groups, yet the full scan is repeated per token. Two following factors increase the severity: 1. groupcomments runs first in group() (grouping.py:439), before the groupmatching token-count guard (grouping.py:34-39). So the entire quadratic cost is paid even on oversized input. MAXGROUPINGTOKENS does not provide protection on this vector. 2. It sits on the primary sanitizer path: format(sql, stripcomments=True), used by query loggers, SQL firewalls, ORMs, and…
Recommended action: Upgrade to 0.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The documented Python and PHP output modes generate source-code snippets from caller-supplied SQL. Their output filters escape quote characters without first escaping existing backslashes. Crafted SQL can therefore neutralize the generated quote escape, terminate the intended language string, and place attacker-controlled code into the generated snippet. If a downstream consumer executes or imports that generated source, the injected code runs in the consumer's environment. Details The Python output filter places SQL in a single-quoted string and replaces each single quote with an escaped quote. The PHP output filter performs the equivalent operation for a double-quoted string. Neither transformation escapes pre-existing backslashes before escaping quotes. A backslash supplied immediately before a quote causes the generated backslash to be escaped instead of the quote, allowing the quote to close the string. The affected modes are exposed through sqlparse.format(...,…
Recommended action: Upgrade to 0.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The below gist hangs while attempting to format a long list of tuples. This was found while drafting a regression test for Dja ngo 5.2's composite primary key feature, which allows querying composite fields with tuples. ###
Recommended action: Upgrade to 0.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Passing a heavily nested list to sqlparse.parse() leads to a Denial of Service due to RecursionError. Details + PoC Running the following code will raise Maximum recursion limit exceeded exception: We expect a traceback of RecursionError: Fix suggestion The flatten() function of TokenList class should limit the recursion to a maximal depth: Impact Denial of Service (the impact depends on the use). Anyone parsing a user input with sqlparse.parse() is affected.
Recommended action: Upgrade to 0.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The SQL parser contains a regular expression that is vulnerable to ReDoS (Regular Expression Denial of Service). The vulnerability may lead to Denial of Service (DoS). Patches This issues has been fixed in sqlparse 0.4.4. Workarounds None. References This issue was discovered and reported by GHSL team member @erik-krogh (Erik Krogh Kristensen). - Commit that introduced the vulnerability: e75e35869473832a1eb67772b1adfee2db11b85a
Recommended action: Upgrade to 0.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The formatter function that strips comments from a SQL contains a regular expression that is vulnerable to ReDoS (Regular Expression Denial of Service). The regular expression may cause exponential backtracking on strings containing many repetitions of '\r\n' in SQL comments. Patches The issues has been fixed in sqlparse 0.4.2. Workarounds Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround don't use the sqlformat.format function with keyword stripcomments=True or the --strip-comments command line flag when using the sqlformat command line tool. References This issue was discovered by GitHub team members @erik-krogh and @yoff. It was found using a CodeQL query which identifies inefficient regular expressions. You can see the results of the query on python-sqlparse by following this link. For more information If you have any questions or comments about this advisory: Open an issue in sqlparse issue…
Recommended action: Upgrade to 0.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.