CVE-2026-59894

Summary

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(..., output_format='python'), sqlparse.format(..., output_format='php'), and the corresponding sqlformat -l options. Formatting produces the injected source but does not itself execute it; code execution occurs when a downstream workflow treats the generated snippet as Python or PHP code.

Relevant code locations:

• sqlparse/formatter.py:193 — selection of the output-language filters
• sqlparse/filters/output.py:45 — opening of the generated Python string
• sqlparse/filters/output.py:65 — incomplete Python quote escaping
• sqlparse/filters/output.py:91 — opening of the generated PHP string
• sqlparse/filters/output.py:114 — incomplete PHP quote escaping

PoC

A complete validated reproduction is attached as output_format_snippet_injection-poc.zip. The archive contains reproduction/ at its root, uses Git and Docker, and validates the Python output path by generating and executing a snippet containing a controlled marker-file write.

Extract the archive beside this report, then run:

./reproduction/run.sh

Observed result:

The generated Python snippet placed the attacker-controlled pathlib.Path(...).write_text(...) expression outside the intended SQL string. Executing the snippet wrote the expected proof marker, emitted EVOHUNT_OUTPUT_FORMAT_INJECTION_VERIFIED, and completed successfully.

Verification method:

The verification helper calls sqlparse.format(..., output_format='python'), executes the generated snippet, and fails unless the injected Python expression writes the exact proof marker file.

Limitations:

No reproduction blocker was recorded. The attached harness directly verifies the Python output path; exploitation also requires a downstream consumer to execute or import the generated source.

Impact

This is source-code injection in the opt-in Python and PHP snippet-generation modes. An attacker who controls SQL converted by one of these modes can inject language code into the generated artifact. If that artifact is subsequently executed, the attacker can run code with the permissions and access of the downstream Python or PHP process.

The demonstrated end-to-end result is code execution through a generated Python snippet. Formatting the SQL alone does not execute the payload, and ordinary parsing, splitting, or formatting without these output modes is not shown to be affected.

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)

A non-validating SQL parser.

Security Fix(es):

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, 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.(CVE-2026-84305)

Summary

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(..., output_format='python'), sqlparse.format(..., output_format='php'), and the corresponding sqlformat -l options. Formatting produces the injected source but does not itself execute it; code execution occurs when a downstream workflow treats the generated snippet as Python or PHP code.

Relevant code locations:

• sqlparse/formatter.py:193 — selection of the output-language filters
• sqlparse/filters/output.py:45 — opening of the generated Python string
• sqlparse/filters/output.py:65 — incomplete Python quote escaping
• sqlparse/filters/output.py:91 — opening of the generated PHP string
• sqlparse/filters/output.py:114 — incomplete PHP quote escaping

PoC

A complete validated reproduction is attached as output_format_snippet_injection-poc.zip. The archive contains reproduction/ at its root, uses Git and Docker, and validates the Python output path by generating and executing a snippet containing a controlled marker-file write.

Extract the archive beside this report, then run:

./reproduction/run.sh

Observed result:

The generated Python snippet placed the attacker-controlled pathlib.Path(...).write_text(...) expression outside the intended SQL string. Executing the snippet wrote the expected proof marker, emitted EVOHUNT_OUTPUT_FORMAT_INJECTION_VERIFIED, and completed successfully.

Verification method:

The verification helper calls sqlparse.format(..., output_format='python'), executes the generated snippet, and fails unless the injected Python expression writes the exact proof marker file.

Limitations:

No reproduction blocker was recorded. The attached harness directly verifies the Python output path; exploitation also requires a downstream consumer to execute or import the generated source.

Impact

This is source-code injection in the opt-in Python and PHP snippet-generation modes. An attacker who controls SQL converted by one of these modes can inject language code into the generated artifact. If that artifact is subsequently executed, the attacker can run code with the permissions and access of the downstream Python or PHP process.

The demonstrated end-to-end result is code execution through a generated Python snippet. Formatting the SQL alone does not execute the payload, and ordinary parsing, splitting, or formatting without these output modes is not shown to be affected.

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

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