[Django] #37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)

[Django]

#37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)
-------------------------------------+-------------------------------------
Reporter: Paolo | Owner: Paolo Melchiorre
Melchiorre |
Type: | Status: assigned
Cleanup/optimization |
Component: Database | Version: dev
layer (models, ORM) |
Severity: Normal | Keywords: sqlparse
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Django currently requires {{{sqlparse >= 0.5.0}}}. sqlparse 0.6.0 (Aug 13,
2026) fixes several security vulnerabilities, including multiple denial-
of-service issues. To ensure every Django install ships with these fixes,
the minimum required version should be raised to {{{0.6.0}}}.

Changelog: [https://github.com/andialbrecht/sqlparse/blob/master/CHANGELOG
sqlparse CHANGELOG]

=== Vulnerabilities in 0.6.0 that affect Django's usage of sqlparse ===

Django uses sqlparse in the database layer ({{{django.db.backends}}}):

* {{{sqlparse.split()}}} and {{{sqlparse.format(...,
strip_comments=True)}}} in
[https://github.com/django/django/blob/main/django/db/backends/base/operations.py
{{{BaseDatabaseOperations.prepare_sql_script}}}] (migrations/fixtures
SQL).
* {{{sqlparse.format(sql, reindent=True, keyword_case="upper")}}} in
[https://github.com/django/django/blob/main/django/db/backends/base/operations.py#L875
{{{BaseDatabaseOperations.format_debug_sql}}}].
* {{{sqlparse.parse()}}} in the
[https://github.com/django/django/blob/main/django/db/backends/mysql/introspection.py
MySQL] and
[https://github.com/django/django/blob/main/django/db/backends/sqlite3/introspection.py
SQLite] introspection backends.

These code paths are exposed to the following 0.6.0 fixes:

* [https://nvd.nist.gov/vuln/detail/CVE-2026-59893 CVE-2026-59893] — DoS
in the lexer on unclosed dollar-quoted literals or multiline comments
(affects {{{split}}}/{{{parse}}}/{{{format}}}).
* [https://nvd.nist.gov/vuln/detail/CVE-2026-54284 CVE-2026-54284] — DoS
when grouping deeply nested or very wide statements (affects {{{parse}}}
used in introspection).
* [https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-
cfqr-cjx5-5jcm GHSA-cfqr-cjx5-5jcm] — DoS in {{{format(sql,
reindent=True)}}} on long lists of tuples (directly used by
{{{format_debug_sql}}}).
* [https://nvd.nist.gov/vuln/detail/CVE-2026-71491 CVE-2026-71491] — DoS
on statements consisting only of comments (affects
{{{split}}}/{{{format(strip_comments=True)}}} in
{{{prepare_sql_script}}}).

A fifth fix, [https://nvd.nist.gov/vuln/detail/CVE-2026-59894
CVE-2026-59894] (backslash escaping in the {{{python}}}/{{{php}}} output
formatters), does not directly affect Django, as Django does not use those
formatters, but is included for defense in depth.

=== Proposed change ===

Raise the minimum supported version of sqlparse from {{{0.5.0}}} to
{{{0.6.0}}} in:

* [https://github.com/django/django/blob/main/pyproject.toml
pyproject.toml] ({{{dependencies}}})
* [https://github.com/django/django/blob/main/tests/requirements/py3.txt
tests/requirements/py3.txt]
* [https://github.com/django/django/blob/main/tests/requirements/py3
-free-threading.txt tests/requirements/py3-free-threading.txt]
* [https://github.com/django/django/blob/main/docs/internals/contributing
/writing-code/unit-tests.txt docs/internals/contributing/writing-code
/unit-tests.txt]
* [https://github.com/django/django/blob/main/docs/releases/6.2.txt
docs/releases/6.2.txt] (backwards incompatible change note)

There is no Python-version conflict: Django requires {{{>=3.12}}} and
sqlparse 0.6.0 requires {{{>=3.10}}}.

No regression test is added: this is a dependency floor bump with no
change to Django's own behavior, so there is no Django code path to
regress.

=== Testing ===

With sqlparse 0.6.0 installed in a fresh venv, the full test suite
({{{./runtests.py}}}) passes:

{{{
Ran 19750 tests in 47.688s
OK (skipped=1402, expected failures=4)
}}}

Targeted runs of the sqlparse-dependent suites ({{{backends}}},
{{{migrations}}}, {{{fixtures}}}, {{{queries}}}, {{{schema}}}) also pass
with no regressions.

=== AI assistance ===

This report was prepared with assistance from an AI tool, used to: analyze
the sqlparse 0.6.0 changelog, generate the issue text in english. The
findings, and test issue text were reviewed and verified by the reporter.
--
Ticket URL: <https://code.djangoproject.com/ticket/37284>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)
-------------------------------------+-------------------------------------

Reporter: Paolo Melchiorre | Owner: Paolo
Type: | Melchiorre
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: sqlparse | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Paolo Melchiorre):

* has_patch: 0 => 1


Old description:

> Django currently requires {{{sqlparse >= 0.5.0}}}. sqlparse 0.6.0 (Aug
> 13, 2026) fixes several security vulnerabilities, including multiple

> denial-of-service issues. To ensure every Django install ships with these

New description:

Comment:

Patch ready for review: https://github.com/django/django/pull/21796
--
Ticket URL: <https://code.djangoproject.com/ticket/37284#comment:1>

[Django]

#37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)
-------------------------------------+-------------------------------------
Reporter: Paolo Melchiorre | Owner: Paolo
Type: | Melchiorre

Cleanup/optimization | Status: closed

Component: Database layer | Version: dev
(models, ORM) |

Severity: Normal | Resolution: wontfix

Keywords: sqlparse | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Sarah Boyce):

* resolution: => wontfix
* status: assigned => closed

Comment:

Hi Paolo, if you have discovered that Django is vulnerable to an attack,
can you please detail the attack and send the report to the Django
security team: secu...@djangoproject.com
Otherwise, we don't have to bump the minimum supported version
--
Ticket URL: <https://code.djangoproject.com/ticket/37284#comment:2>

[Django]

#37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)
-------------------------------------+-------------------------------------
Reporter: Paolo Melchiorre | Owner: Paolo
Type: | Melchiorre
Cleanup/optimization | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: sqlparse | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Jacob Walls):

I reported one of those CVEs to `sqlparse`. :-)

I agree with Sarah -- our only use of `sqlparse` is with the `--debug-sql`
flag on the test client, which is not attacker controlled, so I don't see
any rush to update here.
--
Ticket URL: <https://code.djangoproject.com/ticket/37284#comment:3>

[Django]

#37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)
-------------------------------------+-------------------------------------
Reporter: Paolo Melchiorre | Owner: Paolo
Type: | Melchiorre
Cleanup/optimization | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: sqlparse | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Paolo Melchiorre):

Thanks Jacob and Sarah.

To be clear, it was obvious to me this wasn't a Django security issue,
which is why I didn't email the security team. ;-)

Obviously I trust your judgment, but could you help me understand why we'd
keep suggesting a package with known security bugs, when there's a version
that fixes them all and is compatible with the current Django versions, as
I genuinely don't follow the rationale for not bumping; I couldn't find
anything in the documentation that forbids the version bump in this case.

BTW thanks to Jacob for reporting one of those CVEs :-)

P.S. this doesn't change anything above, but for completeness, sqlparse is
also used in other files ''(e.g. operations.py, introspection.py)''
besides '--debug-sql'.
--
Ticket URL: <https://code.djangoproject.com/ticket/37284#comment:4>

[Django]

#37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)
-------------------------------------+-------------------------------------
Reporter: Paolo Melchiorre | Owner: Paolo
Type: | Melchiorre
Cleanup/optimization | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: sqlparse | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Jacob Walls):

Replying to [comment:4 Paolo Melchiorre]:

> P.S. this doesn't change anything above, but for completeness, sqlparse
is also used in other files ''(e.g. operations.py, introspection.py)''
besides '--debug-sql'.

Good call, I forgot introspection (`inspectdb`), but the `operations.py`
is just the hook called in `--debug-sql`. I remember a lot of discussion
in #36380 where we were careful to avoid calling `sqlparse` to format SQL
in any non-test request path, even if `DEBUG=True`, specifically to avoid
performance DoS vectors. If there's a case besides `--debug-sql` or
`inspectdb` that is affected, I'd raise it with the Security Team.

Replying to [comment:4 Paolo Melchiorre]:

> Obviously I trust your judgment, but could you help me understand why
we'd keep suggesting a package with known security bugs, when there's a
version that fixes them all and is compatible with the current Django
versions, as I genuinely don't follow the rationale for not bumping;

Certainly. So, I don't understand the minimum version to be a
"suggestion": it's simply the minimum compatible version. As a library, I
think it's better for us to keep the widest possible range of versions.
Imagine another dependency is not compatible with sqlparse 0.6.0. Now
we've made depedency resolution impossible in their environment? Why?
Because of CVEs that Django is not concerned with.
--
Ticket URL: <https://code.djangoproject.com/ticket/37284#comment:5>

[Django]

#37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)
-------------------------------------+-------------------------------------
Reporter: Paolo Melchiorre | Owner: Paolo
Type: | Melchiorre
Cleanup/optimization | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: sqlparse | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Paolo Melchiorre):

Replying to [comment:5 Jacob Walls]:

> Replying to [comment:4 Paolo Melchiorre]:

> > ... could you help me understand why we'd keep suggesting a package

with known security bugs, when there's a version that fixes them all and
is compatible with the current Django versions, as I genuinely don't
follow the rationale for not bumping;
>
> Certainly. So, I don't understand the minimum version to be a
"suggestion": it's simply the minimum compatible version. As a library, I
think it's better for us to keep the widest possible range of versions.
Imagine another dependency is not compatible with sqlparse 0.6.0. Now
we've made depedency resolution impossible in their environment? Why?
Because of CVEs that Django is not concerned with.

Thanks Jacob, the explanation is clear and makes sense.

I I understood correctly the main point is: if someone in their Django
project has another dependency that isn't compatible with sqlparse 0.6.0,
bumping our minimum required version breaks their environment. That would
require either a dependency with an explicit `sqlparse<0.6.0` constraint
(which is itself a bad behavior) or that sqlparse 0.6.0 actually
introduced real backwards-incompatible breaking changes. Seems unlikely,
but I admit it's not impossible.

BTW it's a very good explanation, thanks. I think it would be very useful
for everyone, both contributors and maintainers, if it were written in the
contribution documentation: it would save time for those who open an issue
and for those who then have to close it re-explaining the same motivation
every time, much more useful than a plain wontfix.

I understand maintainer time is precious and scarce, so I'm sincerely
suggesting to capture this rationale in the docs to save everyone's time.
--
Ticket URL: <https://code.djangoproject.com/ticket/37284#comment:6>

[Django]

#37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)
-------------------------------------+-------------------------------------
Reporter: Paolo Melchiorre | Owner: Paolo
Type: | Melchiorre
Cleanup/optimization | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: sqlparse | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Jacob Walls):

Your time is precious too! :-)

Happy to look at a docs tweak, perhaps in the howto-release-django doc, as
a "Post-release" task? Elsewhere in that doc we have links to example
historical commits, and we could link to
d9af197801376fae178761cac12d57178a738cf4 as an example of updating
dependencies in tandem with dropping Python versions.

Or, we could think outside the box and look for a place like
docs/faq/install.txt or similar?
--
Ticket URL: <https://code.djangoproject.com/ticket/37284#comment:7>

[Django]

#37284: Bump minimum sqlparse version from 0.5.0 to 0.6.0 (security fixes)
-------------------------------------+-------------------------------------
Reporter: Paolo Melchiorre | Owner: Paolo
Type: | Melchiorre
Cleanup/optimization | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: sqlparse | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Paolo Melchiorre):

Sorry, I'm leaving for DjangoCon US, so I have no time to deep dive your
question. I think that your first suggestion can be a good starting point.
--
Ticket URL: <https://code.djangoproject.com/ticket/37284#comment:8>