CVE-2026-54284

Summary

sqlparse ships hard limits (MAX_GROUPING_DEPTH=100, MAX_GROUPING_TOKENS=10000) intended to bound parsing work on attacker-supplied SQL, but the path that reaches those limits is itself O(n*depth) 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(n*d) flatten work just to materialize the cached value field, which is then never read for grouped nodes (they override __str__).

This is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to trigger the caps is itself superlinear in payload size.

Affected components

sqlparse 0.5.5 (latest) and every prior version that ships TokenList.__init__. The offending line has existed since the introduction of the cached-value invariant; the recent DoS-protection commit (da67ac1, 2025-12-08) added depth + token caps to _group_matching / _group but left the per-node str(self) materialization untouched.

Vulnerable code (file:line)

sqlparse/sql.py#L162 (release 0.5.5) / sqlparse/sql.py#L167 (current master):

class TokenList(Token):
    __slots__ = 'tokens'

    def __init__(self, tokens=None):
        self.tokens = tokens or []
        [setattr(token, 'parent', self) for token in self.tokens]
        super().__init__(None, str(self))   # ← O(subtree) work per group
        self.is_group = True

    def __str__(self):
        return ''.join(token.value for token in self.flatten())

__str__ recurses via flatten() over the entire subtree below self. Every TokenList constructed during grouping (every Parenthesis, Case, IdentifierList, etc.) runs this on its current children, which themselves recursively call flatten(). For grouping that builds a tree of depth d containing n tokens, the construction cost is O(n * d).

The grouping pipeline that triggers it lives at sqlparse/engine/grouping.py#L80 (group_parenthesis) and sqlparse/engine/grouping.py#L84 (group_case). Both call _group_matching which builds nested Parenthesis / Case TokenList instances bottom-up.

Reachable / How input reaches the sink

sqlparse.parse(sql), sqlparse.format(sql, reindent=True), and sqlparse.split(sql) are the documented entry points and all flow into engine/filter_stack.py:run → engine/grouping.py:group → group_parenthesis / group_case. There is no opt-in flag: the quadratic runs on default configuration whenever attacker-controlled SQL contains nested parentheses, nested CASE WHEN, nested subqueries, or nested ARRAY[] literals.

Real-world consumers that feed user input directly into these entry points include any SQL formatter web service (the sqlformat.org-style class of tools), Django's format_debug_sql (django/db/backends/base/operations.py) used when a debug toolbar shows user-typed SQL, and downstream metadata libraries such as sql-metadata…

A non-validating SQL parser.

Security Fix(es):

sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, TokenList construction and string conversion in sqlparse/sql.py repeatedly flatten nested token subtrees constructed by group_parenthesis and group_case, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split() before depth and token limits terminate processing. This issue is fixed in version 0.6.0.(CVE-2026-54284)

sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, sqlparse/filters/output.py fails to escape existing backslashes before quotes in sqlparse.format output_format='python' and output_format='php' and the corresponding sqlformat -l modes, allowing crafted SQL to terminate the generated string and inject Python or PHP code when a downstream consumer executes or imports the generated source. This issue is fixed in version 0.6.0.(CVE-2026-59894)

sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, group_comments in sqlparse/engine/grouping.py repeatedly rescans comment-only statements before the MAX_GROUPING_TOKENS guard, causing quadratic CPU consumption through sqlparse.parse() and sqlparse.format(sql, strip_comments=True). This issue is fixed in version 0.6.0.(CVE-2026-71491)

A non-validating SQL parser.

Security Fix(es):

sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, TokenList construction and string conversion in sqlparse/sql.py repeatedly flatten nested token subtrees constructed by group_parenthesis and group_case, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split() before depth and token limits terminate processing. This issue is fixed in version 0.6.0.(CVE-2026-54284)

sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, sqlparse/filters/output.py fails to escape existing backslashes before quotes in sqlparse.format output_format='python' and output_format='php' and the corresponding sqlformat -l modes, allowing crafted SQL to terminate the generated string and inject Python or PHP code when a downstream consumer executes or imports the generated source. This issue is fixed in version 0.6.0.(CVE-2026-59894)

sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, group_comments in sqlparse/engine/grouping.py repeatedly rescans comment-only statements before the MAX_GROUPING_TOKENS guard, causing quadratic CPU consumption through sqlparse.parse() and sqlparse.format(sql, strip_comments=True). This issue is fixed in version 0.6.0.(CVE-2026-71491)

Summary

sqlparse ships hard limits (MAX_GROUPING_DEPTH=100, MAX_GROUPING_TOKENS=10000) intended to bound parsing work on attacker-supplied SQL, but the path that reaches those limits is itself O(n*depth) 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(n*d) flatten work just to materialize the cached value field, which is then never read for grouped nodes (they override __str__).

This is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to trigger the caps is itself superlinear in payload size.

Affected components

sqlparse 0.5.5 (latest) and every prior version that ships TokenList.__init__. The offending line has existed since the introduction of the cached-value invariant; the recent DoS-protection commit (da67ac1, 2025-12-08) added depth + token caps to _group_matching / _group but left the per-node str(self) materialization untouched.

Vulnerable code (file:line)

sqlparse/sql.py#L162 (release 0.5.5) / sqlparse/sql.py#L167 (current master):

class TokenList(Token):
    __slots__ = 'tokens'

    def __init__(self, tokens=None):
        self.tokens = tokens or []
        [setattr(token, 'parent', self) for token in self.tokens]
        super().__init__(None, str(self))   # ← O(subtree) work per group
        self.is_group = True

    def __str__(self):
        return ''.join(token.value for token in self.flatten())

__str__ recurses via flatten() over the entire subtree below self. Every TokenList constructed during grouping (every Parenthesis, Case, IdentifierList, etc.) runs this on its current children, which themselves recursively call flatten(). For grouping that builds a tree of depth d containing n tokens, the construction cost is O(n * d).

The grouping pipeline that triggers it lives at sqlparse/engine/grouping.py#L80 (group_parenthesis) and sqlparse/engine/grouping.py#L84 (group_case). Both call _group_matching which builds nested Parenthesis / Case TokenList instances bottom-up.

Reachable / How input reaches the sink

sqlparse.parse(sql), sqlparse.format(sql, reindent=True), and sqlparse.split(sql) are the documented entry points and all flow into engine/filter_stack.py:run → engine/grouping.py:group → group_parenthesis / group_case. There is no opt-in flag: the quadratic runs on default configuration whenever attacker-controlled SQL contains nested parentheses, nested CASE WHEN, nested subqueries, or nested ARRAY[] literals.

Real-world consumers that feed user input directly into these entry points include any SQL formatter web service (the sqlformat.org-style class of tools), Django's format_debug_sql (django/db/backends/base/operations.py) used when a debug toolbar shows user-typed SQL, and downstream metadata libraries such as sql-metadata…

Red Hat Lightwell has released sqlparse 0.5.5+rhlw.1 with backported fixes for CVE-2026-54284, CVE-2026-59893, CVE-2026-59894, CVE-2026-71491, and CVE-2026-84305.

CVE-2026-54284: sqlparse: TokenList.init materializes O(subtree) value per group, causing CPU DoS before depth/token caps trigger

CVE-2026-59893: sqlparse: Inefficient Regex Handling of Dollar-Quoted SQL Literals Leads to ReDoS (Denial of Service)

CVE-2026-59894: sqlparse: Generated Python and PHP snippets allow SQL string breakout through unescaped backslashes

CVE-2026-71491: sqlparse: Quadratic O(n²) DoS in group_comments

CVE-2026-84305: sqlparse: Reindentation of tuple lists causes near-cap quadratic CPU consumption

This patched artifact is a drop-in replacement for sqlparse 0.5.5 from PyPI.

sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, TokenList construction and string conversion in sqlparse/sql.py repeatedly flatten nested token subtrees constructed by group_parenthesis and group_case, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split() before depth and token limits terminate processing. This issue is fixed in version 0.6.0.

These are all security issues fixed in the python313-sqlparse-0.6.0-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-sqlparse fixes the following issues:

• CVE-2026-54284: high algorithm complexity when parsing SQL payloads with hundreds of nesting levels can lead to denial of service via excessive resource consumption (bsc#1275459).
• CVE-2026-59893: quadratic complexity when processing unmatched dollar-quoted literal and multiline-comment delimiters can lead to denial of service (bsc#1275461).
• CVE-2026-59894: improper backlash escaping allows for injection of Python or PHP code via a crafted SQL input (bsc#1275460).
• CVE-2026-71491: quadratic complexity in group_comments when processing comment-only statements can lead to denial of services (bsc#1275466).
• Incomplete GHSA-27jp-wm6q-gp25 patch (bsc#1268597).

Root has patched CVE-2026-54284 in the sqlparse package for Root:PyPI. Multiple fixed versions available.

This update for python-sqlparse fixes the following issues:

• CVE-2026-54284: high algorithm complexity when parsing SQL payloads with hundreds of nesting levels can lead to denial of service via excessive resource consumption (bsc#1275459).
• CVE-2026-59893: quadratic complexity when processing unmatched dollar-quoted literal and multiline-comment delimiters can lead to denial of service (bsc#1275461).
• CVE-2026-59894: improper backlash escaping allows for injection of Python or PHP code via a crafted SQL input (bsc#1275460).
• CVE-2026-71491: quadratic complexity in group_comments when processing comment-only statements can lead to denial of services (bsc#1275466).
• Incomplete GHSA-27jp-wm6q-gp25 patch (bsc#1268597).

This update for python-sqlparse fixes the following issues:

• CVE-2026-54284: TokenList.init materializes O(subtree) value per group, causing CPU DoS before depth/token caps trigger (bsc#1275459).
• CVE-2026-59893: Inefficient Regex Handling of Dollar-Quoted SQL Literals Leads to ReDoS (bsc#1275461).
• CVE-2026-59894: Generated Python and PHP snippets allow SQL string breakout through unescaped backslashes (bsc#1275460).
• CVE-2026-71491: quadratic O(n2) DoS in group_comments (bsc#1275466).

This update for python3-sqlparse fixes the following issues:

• CVE-2026-54284: high algorithm complexity when parsing SQL payloads with hundreds of nesting levels can lead to denial of service via excessive resource consumption (bsc#1275459).
• CVE-2026-59893: quadratic complexity when processing unmatched dollar-quoted literal and multiline-comment delimiters can lead to denial of service (bsc#1275461).
• CVE-2026-59894: improper backlash escaping allows for injection of Python or PHP code via a crafted SQL input (bsc#1275460).
• CVE-2026-71491: quadratic complexity in group_comments when processing comment-only statements can lead to denial of services (bsc#1275466).

This update for python-sqlparse fixes the following issues:

• CVE-2026-54284: high algorithm complexity when parsing SQL payloads with hundreds of nesting levels can lead to denial of service via excessive resource consumption (bsc#1275459).
• CVE-2026-59893: quadratic complexity when processing unmatched dollar-quoted literal and multiline-comment delimiters can lead to denial of service (bsc#1275461).
• CVE-2026-59894: improper backlash escaping allows for injection of Python or PHP code via a crafted SQL input (bsc#1275460).
• CVE-2026-71491: quadratic complexity in group_comments when processing comment-only statements can lead to denial of services (bsc#1275466).

This update for python-sqlparse fixes the following issues:

• CVE-2026-54284: TokenList.init materializes O(subtree) value per group, causing CPU DoS before depth/token caps trigger (bsc#1275459).
• CVE-2026-59893: Inefficient Regex Handling of Dollar-Quoted SQL Literals Leads to ReDoS (bsc#1275461).
• CVE-2026-59894: Generated Python and PHP snippets allow SQL string breakout through unescaped backslashes (bsc#1275460).
• CVE-2026-71491: quadratic O(n2) DoS in group_comments (bsc#1275466).

It was discovered that SQL parse contained multiple algorithmic complexity flaws when parsing SQL statements with deeply nested parentheses, comments, or dollar-quoted string literals. An attacker could use this issue to cause SQL parse to consume excessive CPU resources, resulting in a denial of service.