Feb. 3, 2026

Django security releases issued: 6.0.2, 5.2.11, and 4.2.28

In accordance with our security release policy, the Django team is issuing releases for Django 6.0.2, Django 5.2.11, and Django 4.2.28. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

CVE-2025-13473: Username enumeration through timing difference in mod_wsgi authentication handler

The django.contrib.auth.handlers.modwsgi.check_password() function for authentication via mod_wsgi allowed remote attackers to enumerate users via a timing attack.

Thanks to Stackered for the report.

This issue has severity "low" according to the Django security policy.

CVE-2025-14550: Potential denial-of-service vulnerability via repeated headers when using ASGI

When receiving duplicates of a single header, ASGIRequest allowed a remote attacker to cause a potential denial-of-service via a specifically created request with multiple duplicate headers. The vulnerability resulted from repeated string concatenation while combining repeated headers, which produced super-linear computation resulting in service degradation or outage.

Thanks to Jiyong Yang for the report.

This issue has severity "moderate" according to the Django security policy.

CVE-2026-1207: Potential SQL injection via raster lookups on PostGIS

Raster lookups on GIS fields (only implemented on PostGIS) were subject to SQL injection if untrusted data was used as a band index.

As a reminder, all untrusted user input should be validated before use.

Thanks to Tarek Nakkouch for the report.

This issue has severity "high" according to the Django security policy.

CVE-2026-1285: Potential denial-of-service vulnerability in django.utils.text.Truncator HTML methods

django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True) and truncatechars_html and truncatewords_html template filters were subject to a potential denial-of-service attack via certain inputs with a large number of unmatched HTML end tags, which could cause quadratic time complexity during HTML parsing.

Thanks to Seokchan Yoon for the report.

This issue has severity "moderate" according to the Django security policy.

CVE-2026-1287: Potential SQL injection in column aliases via control characters

FilteredRelation was subject to SQL injection in column aliases via control characters, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias().

Thanks to Solomon Kebede for the report.

This issue has severity "high" according to the Django security policy.

CVE-2026-1312: Potential SQL injection via QuerySet.order_by and FilteredRelation

QuerySet.order_by() was subject to SQL injection in column aliases containing periods when the same alias was, using a suitably crafted dictionary, with dictionary expansion, used in FilteredRelation.

Thanks to Solomon Kebede for the report.

This issue has severity "high" according to the Django security policy.

Affected supported versions

  • Django main
  • Django 6.0
  • Django 5.2
  • Django 4.2

Resolution

Patches to resolve the issue have been applied to Django's main, 6.0, 5.2, and 4.2 branches. The patches may be obtained from the following changesets.

CVE-2025-13473: Username enumeration through timing difference in mod_wsgi authentication handler

CVE-2025-14550: Potential denial-of-service vulnerability via repeated headers when using ASGI

CVE-2026-1207: Potential SQL injection via raster lookups on PostGIS

CVE-2026-1285: Potential denial-of-service vulnerability in django.utils.text.Truncator HTML methods

CVE-2026-1287: Potential SQL injection in column aliases via control characters

CVE-2026-1312: Potential SQL injection via QuerySet.order_by and FilteredRelation

The following releases have been issued

The PGP key ID used for this release is Jacob Walls: 131403F4D16D8DC7

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance, nor via the Django Forum. Please see our security policies for further information.