sqlparse CVE-2026-59894

Exploitation requires two simultaneous conditions: first, sqlparse.format() must be called with output_format='python' or output_format='php' (or the sqlformat CLI with -l python or -l php); default sqlparse usage without these modes is entirely unaffected. Second, a downstream consumer must execute or import the generated source-code snippet - if the snippet is only stored, logged, or displayed to a user, no code execution occurs and there is no impact. The attacker must control or influence the SQL string passed to the formatter; this may be direct (the SQL is user-supplied input) or indirect (the SQL is read from a file or database record the attacker can influence). CVSS PR:N indicates no authentication requirement from sqlparse's own perspective, but authentication to the upstream application that accepts SQL input is determined by that application's own access controls, not by sqlparse. Exploitation is strictly limited to environments where both conditions hold concurrently.

The CVSS 4.0 score of 6.2 accurately captures the indirect exploitation model: sqlparse itself suffers no direct impact (VC:N/VI:N/VA:N), but the subsequent system that executes the generated snippet faces high confidentiality and integrity impact (SC:H/SI:H). The AV:L assignment in the provided vector likely reflects CLI-centric usage patterns, but library deployments in web applications - where attacker-supplied SQL arrives over the network and the application subsequently executes or imports generated snippets - materially broaden the realistic attack surface beyond local scope. The UI:P metric is the most consequential limiting factor: exploitation is categorically impossible unless a downstream pipeline treats the generated snippet as executable code, which is a non-default and architecturally intentional deployment pattern rather than an incidental misconfiguration. The absence of a CISA KEV listing indicates no confirmed widespread active exploitation, and the targeted PoC nature (requiring Docker and a custom reproduction harness) is consistent with researcher-grade rather than commodity exploitation. That said, the existence of a validated PoC lowers the barrier for motivated actors, and any organization - even a mid-sized municipal IT team in olsztyn running a SQL-to-script code-generation workflow - should treat this as a high-priority remediation given the scope of potential downstream impact. Risk is moderate to high for pipelines that ingest externally influenced SQL and execute formatted output; risk is negligible for uses of sqlparse that do not involve code-generation output modes.

An attacker submits SQL such as SELECT '\'' FROM t to an application that calls sqlparse.format(sql, output_format='python') and subsequently executes the returned snippet via exec(). The formatter escapes the backslash into \\, leaving the single quote unescaped; the generated snippet reads sql = '\\'' + injected_code + '' - the injected_code appears outside the string literal and executes in the application's Python environment. A fully validated Docker-based proof-of-concept confirming this exact path, including a controlled file-write marker as evidence of code execution, is publicly available in the GHSA-3496-9g83-7v6x advisory attachment.