GHSA-cfqr-cjx5-5jcm
Fix: andialbrecht/sqlparse@a51df6dGHSA-cfqr-cjx5-5jcm is a CWE-407 vulnerability in sqlparse. O3 Security confirms whether GHSA-cfqr-cjx5-5jcm is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
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 GHSA-cfqr-cjx5-5jcm.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
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.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for sqlparse. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update sqlparse to 0.6.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cfqr-cjx5-5jcm 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.
How O3 protects you
O3 pinpoints whether GHSA-cfqr-cjx5-5jcm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-cfqr-cjx5-5jcm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-cfqr-cjx5-5jcm in your dependencies?
O3 detects GHSA-cfqr-cjx5-5jcm across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.