CVE-2026-84305 — sqlparse
Fix: andialbrecht/sqlparse@a51df6dCVE-2026-84305 is a CWE-407 vulnerability in sqlparse. A fix is available for sqlparse — see the affected versions and patch details below.
sqlparse: Reindentation of tuple lists causes near-cap quadratic CPU consumption
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-84305.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
sqlparseReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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._get_offset() joins the tokens returned by _flatten_up_to_token() 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 tuple list completes grouping below the configured token cap and then enters the expensive reindentation path; a slightly larger input may instead be rejected quickly by the cap.
Relevant code locations:
sqlparse/formatter.py:170— enablingReindentFiltersqlparse/filters/reindent.py:30— repeated flattening from the statement startsqlparse/filters/reindent.py:44— prefix joining for offset calculationsqlparse/filters/reindent.py:216— tuple-list processing path
PoC
A complete validated reproduction is attached as reindent_tuple_list_cpu_dos-poc.zip. The archive contains reproduction/ at its root, uses Git and Docker, and compares two same-shape tuple-list inputs formatted with reindentation enabled.
Extract the archive beside this report, then run:
./reproduction/run.sh
Observed result:
The 600-tuple baseline completed in 0.649 seconds, while the below-cap 1,425-tuple input completed in 4.999 seconds. The run emitted EVOHUNT_REINDENT_DOS_VERIFIED and completed successfully.
Verification method:
The verification helper formats two same-shape tuple-list payloads with reindent=True and fails unless the larger payload completes successfully, takes at least 2.0 seconds, and takes at least 4x the baseline.
Limitations:
No reproduction blocker was recorded. Timing varies by host, and exploitation requires the reindentation option or corresponding CLI mode to be enabled.
Impact
This is a CPU resource-exhaustion vulnerability in workflows that reindent attacker-controlled SQL. A small crafted tuple-list input can occupy a worker for several seconds, enabling request delays, reduced throughput, or worker starvation when payloads are processed repeatedly or concurrently.
The affected reindentation behavior is opt-in, and sqlparse itself does not provide network exposure; reachability depends on the consuming application or CLI workflow. The demonstrated effect is CPU consumption in a single formatting call, not process termination, code execution, or confidentiality or integrity impact.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | sqlparse | all versions | 0.6.0pip install --upgrade 'sqlparse==0.6.0' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for sqlparse, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update sqlparse to 0.6.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-84305 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
A denial of service vulnerability was found in sqlparse, a Python SQL parser library. When sqlparse.format() is invoked with the reindent=True option, processing specially crafted parenthesized tuple lists triggers quadratic CPU consumption due to repeated token tree traversal during offset calculation. This can cause…
For general mitigation guidance: Avoid using sqlparse.format() with reindent=True on untrusted input. If SQL formatting is required, either disable reindentation or implement request size limits and timeouts to prevent resource exhaustion. Update to sqlparse 0.6.0 or later, which fixes the quadratic behavior. Note that Red Hat products do not require mitigation as they do not use the vulnerable functionality.Source: Red Hat security advisory for CVE-2026-84305 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2026-84305 in your dependencies?
Find it across PyPI, including transitive dependencies.