dbt-core v1.11.14 - sqlparse Parser DoS Dependency Update

dbt-core v1.11.14 was published on August 20, 2026. This stable patch sets the required sqlparse range to >=0.5.5,<0.7.0, and its notes identify sqlparse 0.6.0 as the fixed release for four parser denial of service CVEs.

The full release notes and downloads are on the GitHub release page.

The only listed change in v1.11.14 is the sqlparse requirement. There is no listed adapter change, command option, project setting, or model behavior change. For platform teams, this is a package resolution release rather than a new feature release.

The new constraint has two useful boundaries. sqlparse 0.5.5 remains the minimum accepted version, while 0.7.0 is excluded. Version 0.6.0 now fits inside that window, and the release notes name it as the version containing the security fixes. The associated work is tracked in issue 15988.

That distinction matters for locked environments. The constraint permits 0.6.0, but it also permits 0.5.5 and other versions below 0.6.0. A dependency resolver working from an existing lock can therefore produce an environment that satisfies the dbt-core requirement without selecting the fixed release named in the notes. The tag changes the allowed range. It does not prove which parser version is installed in a given image or virtual environment.

The release notes associate sqlparse 0.6.0 with fixes for four parser denial of service issues:

  • CVE-2026-54284
  • CVE-2026-59893
  • CVE-2026-59894
  • CVE-2026-71491

For data teams, the relevant boundary is SQL parsing before warehouse execution. Automated jobs commonly parse project SQL during validation and compilation. A parser denial of service can consume worker time before a query reaches the warehouse, so warehouse query limits are not a substitute for updating the parser dependency.

The notes do not provide trigger strings, severity scores, affected input shapes, or separate mitigations for the four CVEs. They also do not claim changes to adapter execution or warehouse behavior. Keep the response scoped to the dependency: update it, verify the installed version, and run the normal project validation path. Claims about exploit conditions need evidence beyond this release entry.

Updating to dbt-core v1.11.14 is the first step. The next step is to regenerate the environment lock or dependency inventory and check the resolved sqlparse version directly. If that result is below 0.6.0, the environment can satisfy >=0.5.5,<0.7.0 while still missing the fixed release identified by the project.

Use the same package manager that builds the production image. Inspect its lock output and the installed package list rather than assuming a clean resolver run occurred. For a pip based environment, python -m pip show sqlparse reports the installed version. Container builds should make the same check against the final image, since an earlier build stage or cached dependency layer can differ from the runtime artifact.

After resolution, run the existing dbt parse or dbt compile checks across the full project. This release lists no migration step and no breaking interface change, but 0.6.0 is still a parser version change. A full project pass is the practical compatibility check for macros and SQL forms that are uncommon in smaller test selections.

The upper bound remains <0.7.0. Do not remove that ceiling merely to silence a resolver conflict. If another dependency prevents 0.6.0 from being selected, identify the conflicting constraint and update it deliberately.