GHSA-27jp-wm6q-gp25

What it actually does

The flaw is a denial-of-service condition in the Python package sqlparse. When vulnerable versions of sqlparse format specially crafted SQL-like input involving a list of tuples, the formatter can consume excessive CPU and/or memory, causing the calling process to slow dramatically, hang, exhaust resources, or become unavailable. The impact depends on where sqlparse is used: applications that parse or format attacker-controlled SQL text are at higher risk than applications that only process trusted internal SQL strings.

Why it matters to the business

Successful exploitation can degrade or interrupt services that rely on sqlparse for SQL formatting, inspection, logging, query tooling, administrative interfaces, or developer-facing features. The most likely consequence is service instability or outage rather than data theft. Because sqlparse is a widely used PyPI dependency and may be pulled in transitively by frameworks, database tools, security scanners, or observability components, organizations should treat this as a dependency hygiene and availability risk even though it is not listed in CISA KEV and no public exploit maturity is indicated.

How an attack unfolds

An attacker first identifies an application feature or API path that accepts SQL text or SQL-like input and passes that input to sqlparse formatting functionality. The attacker then submits a crafted payload containing a problematic list-of-tuples structure that triggers inefficient processing in the vulnerable formatter. If the application processes the payload synchronously, worker threads or processes can become CPU-bound or memory-constrained. Repeated requests can amplify the effect, potentially exhausting application capacity, triggering restarts, delaying legitimate requests, or causing an availability incident. Exploitation does not require code execution or authentication unless the vulnerable parsing feature is itself access-controlled.

How to fix it

Upgrade sqlparse to version 0.5.4 or later wherever it is installed, including direct and transitive dependencies. For Python environments, update dependency manifests and lock files, rebuild application images, and redeploy affected services. Use package-management controls such as `pip install --upgrade sqlparse>=0.5.4`, updated `requirements.txt`, `constraints.txt`, `poetry.lock`, `Pipfile.lock`, or equivalent build metadata. If immediate upgrade is not possible, reduce exposure by preventing untrusted users from reaching SQL formatting functionality, enforcing strict input size and complexity limits, applying request timeouts, isolating parsing/formatting work in bounded worker pools, and rate-limiting endpoints that invoke SQL parsing.

How to confirm the fix worked

Confirm that all runtime environments, containers, virtual environments, build artifacts, and dependency lock files resolve sqlparse to 0.5.4 or later. Run `python -m pip show sqlparse`, `pip freeze`, `pipdeptree`, `poetry show sqlparse`, or software composition analysis tooling to identify vulnerable versions. Validate that redeployed application instances are using the upgraded package, not only that source manifests were changed. For exposure testing, review code paths for `sqlparse.format`, `sqlparse.parse`, or related formatter usage on externally supplied input, and perform controlled performance testing with representative malformed inputs to ensure requests fail safely under configured timeouts and resource limits.

Typical attack path

1. Identify an exposed feature that accepts SQL text, query snippets, filter expressions, report definitions, database-console input, or other content later processed by sqlparse.
2. Determine whether the feature invokes sqlparse formatting on user-supplied input.
3. Submit a crafted SQL-like payload involving a list of tuples that triggers excessive processing in vulnerable sqlparse versions.
4. Observe elevated latency, request timeouts, worker saturation, memory growth, or process restarts.
5. Repeat or parallelize requests to sustain denial of service against the affected application component.

How to detect it

To assess whether exploitation has already occurred, focus on availability and resource-exhaustion evidence rather than malware indicators. Review application, API gateway, web server, WAF, APM, container, and host telemetry for bursts of requests to endpoints that accept SQL text or query-like input, followed by high CPU usage, memory pressure, worker timeouts, process restarts, container OOM kills, or elevated 500/502/503/504 responses. Correlate slow request traces with application stack traces or logs referencing sqlparse formatter functions. In Python services, inspect error logs, profiling snapshots, and APM traces for long-running calls into `sqlparse.format`, `sqlparse.engine`, `sqlparse.filters`, or formatter-related code. Because no specific public exploit payload or threat actor activity is identified, detection should rely on behavioral patterns: repeated unusually large or complex SQL-like submissions, anomalous request volume from a small set of sources, and resource saturation aligned to parsing or formatting operations.

What your security team should do

• Inventory all applications, containers, serverless functions, CI jobs, and developer tools using sqlparse, including transitive dependency usage.
• Prioritize upgrades to sqlparse 0.5.4 or later for internet-facing services, APIs, multi-tenant tools, and any feature that formats user-supplied SQL text.
• Regenerate and commit dependency lock files, then rebuild and redeploy affected artifacts to ensure the fixed package is actually present at runtime.
• Add or verify input size limits, request timeouts, worker isolation, and rate limiting around SQL formatting or parsing features.
• Search application logs and observability data for unexplained spikes in CPU, memory, request duration, timeout rates, and 5xx responses on endpoints that process SQL-like input.
• Add dependency-scanning policy checks to prevent vulnerable sqlparse versions from being reintroduced in future builds.