CVE-2026-54284 discloses a resource exhaustion vulnerability in sqlparse versions before 0.6.0, stemming from quadratic complexity in token flattening that can be triggered by deeply nested SQL input. The CVSS 8.7 rating is misleading in one critical respect: the library already contained depth and token limits that would terminate processing before unbounded resource consumption. Whether these were intended as security boundaries or incidental safeguards is unknown—what is certain is that applications relying on sqlparse were not as exposed as the severity score implies.
Your priority is determining whether sqlparse receives attacker-controlled SQL input in your environment. This is not the typical case: most applications pass trusted SQL (from their own logic or validated sources) to sqlparse for formatting or analysis. If your deployment fits this pattern, the practical risk is lower than the CVSS suggests. However, if you have user-facing code that routes arbitrary SQL through sqlparse.parse(), sqlparse.format(), or sqlparse.split(), you have a DoS vector regardless of the 0.6.0 patch.
The 0.6.0 release changes token construction semantics. Before patching, audit your codebase for dependencies on specific tokenization behavior—applications that rely on token ordering, depth characteristics, or the exact structure of parsed output may experience behavioral changes. The EPSS score of 0.00263 reflects low actual exploitation probability, which aligns with the practical reality that this attack requires a specific input chain that most deployments don't expose.
Actionable steps: inventory your dependencies to find sqlparse (it's commonly pulled by ORMs and logging libraries), trace whether untrusted SQL can reach it, test 0.6.0 in staging to validate tokenization-dependent code, and monitor for parsing-related errors in your logs after upgrading.