CVE-2026-59893

Summary

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 SQL_REGEX:

# sqlparse/keywords.py:33
(r'((?<![\w\"\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1', tokens.Literal),

This pattern first captures a dollar-quote delimiter (e.g., $tag$) into group 1, then attempts to match any characters ([\s\S]*?) up to the same delimiter again via backreference \1. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the remaining string, yielding O(N²) total regex work.

The lexer applies this regex at every character position (sqlparse/lexer.py:136-138):

# sqlparse/lexer.py:136-138
for pos, char in iterable:
    for rexmatch, action in self._SQL_REGEX:
        m = rexmatch(text, pos)

The data flow from public API to the vulnerable sink is:

1. sqlparse/__init__.py:20 — parse(sql) accepts caller-controlled SQL.
2. sqlparse/__init__.py:29 — delegates to parsestream(sql, encoding).
3. sqlparse/__init__.py:43 — FilterStack.run(stream, encoding) is invoked.
4. sqlparse/engine/filter_stack.py:31 — lexer.tokenize(sql, encoding) is called with no length limit or timeout.
5. sqlparse/lexer.py:137 — every regex in _SQL_REGEX is tried at the current position.
6. sqlparse/keywords.py:33 — the backreference regex performs repeated delimiter searches.

The MAX_GROUPING_TOKENS = 10000 limit in sqlparse/engine/grouping.py:20 fires only after lexing completes and does not bound regex CPU time. There is no input length check, delimiter count check, or regex timeout before the sink.

Empirically measured scaling confirms super-linear complexity:

| Input (N unique openers) | Bytes | Elapsed | |--------------------------|--------|----------| | 250 | 1,889 | 0.066 s | | 500 | 3,889 | 0.144 s | | 1,000 | 7,889 | 0.397 s | | 2,000 | 16,889 | 1.314 s |

The timing ratio from n=1000 to n=2000 is 3.31× (input doubled → time tripled), confirming O(n²) growth.

PoC

Prerequisites: Python 3.x with sqlparse installed (tested against version 0.5.6.dev0, commit c923da9).

Using Docker (isolated reproduction):

# Build from the repository root (parent of vuln-001/)
docker build -t sqlparse-vuln001 -f vuln-001/Dockerfile .

# Run with no network access
docker run --rm --network=none sqlparse-vuln001

Direct Python reproduction:

import time
import sqlparse
from sqlparse.exceptions import SQLParseError

def make_payload(n: int) -> str:
    # N unique unmatched dollar-quote openers — none have a matching closing delimiter
    return " ".join(f"$a{i}$x" for i in range(n))

for n in [250, 500, 1000, 2000]:
    payload = make_payload(n)
    t0 = time.perf_counter()
    try:
        sqlparse.parse(payload)
        status = "ok"
    except SQLParseError as e:
        status = f"SQLParseError: {e}"
    elapsed =…

A non-validating SQL parser.

Security Fix(es):

Summary

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 SQL_REGEX:

# sqlparse/keywords.py:33
(r'((?<![\w\"\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1', tokens.Literal),

This pattern first captures a dollar-quote delimiter (e.g., $tag$) into group 1, then attempts to match any characters ([\s\S]*?) up to the same delimiter again via backreference \1. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the remaining string, yielding O(N²) total regex work.

The lexer applies this regex at every character position (sqlparse/lexer.py:136-138):

# sqlparse/lexer.py:136-138
for pos, char in iterable:
    for rexmatch, action in self._SQL_REGEX:
        m = rexmatch(text, pos)

The data flow from public API to the vulnerable sink is:

1. sqlparse/__init__.py:20 — parse(sql) accepts caller-controlled SQL.
2. sqlparse/__init__.py:29 — delegates to parsestream(sql, encoding).
3. sqlparse/__init__.py:43 — FilterStack.run(stream, encoding) is invoked.
4. sqlparse/engine/filter_stack.py:31 — lexer.tokenize(sql, encoding) is called with no length limit or timeout.
5. sqlparse/lexer.py:137 — every regex in _SQL_REGEX is tried at the current position.
6. sqlparse/keywords.py:33 — the backreference regex performs repeated delimiter searches.

The MAX_GROUPING_TOKENS = 10000 limit in sqlparse/engine/grouping.py:20 fires only after lexing completes and does not bound regex CPU time. There is no input length check, delimiter count check, or regex timeout before the sink.

Empirically measured scaling confirms super-linear complexity:

| Input (N unique openers) | Bytes | Elapsed | |--------------------------|--------|----------| | 250 | 1,889 | 0.066 s | | 500 | 3,889 | 0.144 s | | 1,000 | 7,889 | 0.397 s | | 2,000 | 16,889 | 1.314 s |

The timing ratio from n=1000 to n=2000 is 3.31× (input doubled → time tripled), confirming O(n²) growth.

PoC

Prerequisites: Python 3.x with sqlparse installed (tested against version 0.5.6.dev0, commit c923da9).

Using Docker (isolated reproduction):

# Build from the repository root (parent of vuln-001/)
docker build -t sqlparse-vuln001 -f vuln-001/Dockerfile .

# Run with no network access
docker run --rm --network=none sqlparse-vuln001

Direct Python reproduction:

import time
import sqlparse
from sqlparse.exceptions import SQLParseError

def make_payload(n: int) -> str:
    # N unique unmatched dollar-quote openers — none have a matching closing delimiter
    return " ".join(f"$a{i}$x" for i in range(n))

for n in [250, 500, 1000, 2000]:
    payload = make_payload(n)
    t0 = time.perf_counter()
    try:
        sqlparse.parse(payload)
   …

Summary

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 SQL_REGEX:

# sqlparse/keywords.py:33
(r'((?<![\w\"\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1', tokens.Literal),

This pattern first captures a dollar-quote delimiter (e.g., $tag$) into group 1, then attempts to match any characters ([\s\S]*?) up to the same delimiter again via backreference \1. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the remaining string, yielding O(N²) total regex work.

The lexer applies this regex at every character position (sqlparse/lexer.py:136-138):

# sqlparse/lexer.py:136-138
for pos, char in iterable:
    for rexmatch, action in self._SQL_REGEX:
        m = rexmatch(text, pos)

The data flow from public API to the vulnerable sink is:

1. sqlparse/__init__.py:20 — parse(sql) accepts caller-controlled SQL.
2. sqlparse/__init__.py:29 — delegates to parsestream(sql, encoding).
3. sqlparse/__init__.py:43 — FilterStack.run(stream, encoding) is invoked.
4. sqlparse/engine/filter_stack.py:31 — lexer.tokenize(sql, encoding) is called with no length limit or timeout.
5. sqlparse/lexer.py:137 — every regex in _SQL_REGEX is tried at the current position.
6. sqlparse/keywords.py:33 — the backreference regex performs repeated delimiter searches.

The MAX_GROUPING_TOKENS = 10000 limit in sqlparse/engine/grouping.py:20 fires only after lexing completes and does not bound regex CPU time. There is no input length check, delimiter count check, or regex timeout before the sink.

Empirically measured scaling confirms super-linear complexity:

| Input (N unique openers) | Bytes | Elapsed | |--------------------------|--------|----------| | 250 | 1,889 | 0.066 s | | 500 | 3,889 | 0.144 s | | 1,000 | 7,889 | 0.397 s | | 2,000 | 16,889 | 1.314 s |

The timing ratio from n=1000 to n=2000 is 3.31× (input doubled → time tripled), confirming O(n²) growth.

PoC

Prerequisites: Python 3.x with sqlparse installed (tested against version 0.5.6.dev0, commit c923da9).

Using Docker (isolated reproduction):

# Build from the repository root (parent of vuln-001/)
docker build -t sqlparse-vuln001 -f vuln-001/Dockerfile .

# Run with no network access
docker run --rm --network=none sqlparse-vuln001

Direct Python reproduction:

import time
import sqlparse
from sqlparse.exceptions import SQLParseError

def make_payload(n: int) -> str:
    # N unique unmatched dollar-quote openers — none have a matching closing delimiter
    return " ".join(f"$a{i}$x" for i in range(n))

for n in [250, 500, 1000, 2000]:
    payload = make_payload(n)
    t0 = time.perf_counter()
    try:
        sqlparse.parse(payload)
        status = "ok"
    except SQLParseError as e:
        status = f"SQLParseError: {e}"
    elapsed =…

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, SQL_REGEX in sqlparse/keywords.py and the per-position loop in sqlparse/lexer.py repeatedly scan unmatched dollar-quoted literal and multiline-comment delimiters, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split(). 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).

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.