CVE-2026-71491

Summary

A comment-only statement (-- c\n*n) may cause a Denial of Service (DoS).

Details

Location: sqlparse/engine/grouping.py:331-341 (group_comments), invoked first in group() at grouping.py:439. Reachable via sqlparse.parse() and sqlparse.format(sql, strip_comments=True).

A statement made of many single-line comments ('-- c\n' repeated) lexes in O(n) but group_comments is O(n²):

def group_comments(tlist):
    tidx, token = tlist.token_next_by(t=T.Comment)
    while token:
        eidx, end = tlist.token_not_matching(
            lambda tk: imt(tk, t=T.Comment) or tk.is_newline, idx=tidx)
        ...
        tidx, token = tlist.token_next_by(t=T.Comment, idx=tidx)

The while loop runs n times and each token_next_by / token_not_matching 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. group_comments runs first in group() (grouping.py:439), before the _group_matching token-count guard (grouping.py:34-39). So the entire quadratic cost is paid even on oversized input. MAX_GROUPING_TOKENS does not provide protection on this vector.
2. It sits on the primary sanitizer path: format(sql, strip_comments=True), used by query loggers, SQL firewalls, ORMs, and migration tools.

PoC

Tested using Python 3.14:

import time, sqlparse
for n in (1000, 2000, 4000):
    s = "-- c\n" * n
    t = time.perf_counter()
    sqlparse.format(s, strip_comments=True)
    print(f"n={n:5d}  format(strip_comments)={1000*(time.perf_counter()-t):7.1f} ms")

Output:

n= 1000  format(strip_comments)=  106.0 ms
n= 2000  format(strip_comments)=  403.3 ms
n= 4000  format(strip_comments)= 1602.8 ms

Time increase of ~4× per 2× input (quadratic). parse() shows the identical curve. Instrumented scan counts are exactly 1.0M / 4.0M / 16.0M tokens for n=1000/2000/4000. A ~250 KB comment-only payload forces minutes of CPU regardless of the 10000 token cap.

Impact

Denial of Service

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

A comment-only statement (-- c\n*n) may cause a Denial of Service (DoS).

Details

Location: sqlparse/engine/grouping.py:331-341 (group_comments), invoked first in group() at grouping.py:439. Reachable via sqlparse.parse() and sqlparse.format(sql, strip_comments=True).

A statement made of many single-line comments ('-- c\n' repeated) lexes in O(n) but group_comments is O(n²):

def group_comments(tlist):
    tidx, token = tlist.token_next_by(t=T.Comment)
    while token:
        eidx, end = tlist.token_not_matching(
            lambda tk: imt(tk, t=T.Comment) or tk.is_newline, idx=tidx)
        ...
        tidx, token = tlist.token_next_by(t=T.Comment, idx=tidx)

The while loop runs n times and each token_next_by / token_not_matching 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. group_comments runs first in group() (grouping.py:439), before the _group_matching token-count guard (grouping.py:34-39). So the entire quadratic cost is paid even on oversized input. MAX_GROUPING_TOKENS does not provide protection on this vector.
2. It sits on the primary sanitizer path: format(sql, strip_comments=True), used by query loggers, SQL firewalls, ORMs, and migration tools.

PoC

Tested using Python 3.14:

import time, sqlparse
for n in (1000, 2000, 4000):
    s = "-- c\n" * n
    t = time.perf_counter()
    sqlparse.format(s, strip_comments=True)
    print(f"n={n:5d}  format(strip_comments)={1000*(time.perf_counter()-t):7.1f} ms")

Output:

n= 1000  format(strip_comments)=  106.0 ms
n= 2000  format(strip_comments)=  403.3 ms
n= 4000  format(strip_comments)= 1602.8 ms

Time increase of ~4× per 2× input (quadratic). parse() shows the identical curve. Instrumented scan counts are exactly 1.0M / 4.0M / 16.0M tokens for n=1000/2000/4000. A ~250 KB comment-only payload forces minutes of CPU regardless of the 10000 token cap.

Impact

Denial of Service

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, 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.

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-71491 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.