Announce: https://www.djangoproject.com/weblog/2026/jun/03/security-releases/

CVE JSON Record for CVE-2026-6873: https://www.cve.org/CVERecord?id=CVE-2026-6873

CVE JSON Record for CVE-2026-7666: https://www.cve.org/CVERecord?id=CVE-2026-7666

CVE JSON Record for CVE-2026-8404: https://www.cve.org/CVERecord?id=CVE-2026-8404

CVE JSON Record for CVE-2026-35193: https://www.cve.org/CVERecord?id=CVE-2026-35193

CVE JSON Record for CVE-2026-48587: https://www.cve.org/CVERecord?id=CVE-2026-48587

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

CVE-2026-6873: Signed cookie salt namespace collision in django.http.HttpRequest.getsignedcookie

getsignedcookie() derived the signing salt by concatenating the cookie name (key) and salt arguments. When distinct name and salt pairs produced the same concatenation, cookies could be accepted in a context different from the one where they were signed.

Cookies are now signed with an unambiguous salt derivation. For backwards compatibility, cookies signed by older Django versions are accepted until Django 7.0.

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

Thanks to Peng Zhou for the report.

CVE-2026-7666: Potential unencrypted email transmission via STARTTLS in the SMTP backend

When using EMAILUSETLS, a failed STARTTLS handshake could leave a partially-initialized connection that would subsequently be reused for sending email without encryption. This can occur with failsilently=True, as used by sendmail() and BrokenLinkEmailsMiddleware, among others. Connections configured with EMAILUSESSL are not affected.

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

Thanks to Kasper Dupont for the report.

CVE-2026-8404: Potential exposure of private data via case-sensitive Cache-Control directives in UpdateCacheMiddleware

django.middleware.cache.UpdateCacheMiddleware and django.views.decorators.cache.cachepage decorator incorrectly cached responses marked with private Cache-Control directives when using mixed or uppercase values (e.g. Private).

The django.views.decorators.cache.cachecontrol decorator and django.utils.cache.patchcachecontrol() function were not affected, since they normalize directives to lowercase. This issue only affects responses where Cache-Control is set manually.

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

Thanks to Ahmed Badawe for the report.

CVE-2026-35193: Potential exposure of private data via missing Vary: Authorization in UpdateCacheMiddleware

django.middleware.cache.UpdateCacheMiddleware and django.views.decorators.cache.cachepage decorator allowed responses to requests bearing an Authorization header (and without Cache-Control: public) to be cached. To conform with the existing mechanism for constructing cache keys, responses to these requests will now vary on Authorization.

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

Thanks to Shai Berger for the report.

CVE-2026-48587: Potential exposure of private data via whitespace padding in Vary header

django.middleware.cache.UpdateCacheMiddleware incorrectly cached responses whose Vary header values contained leading or trailing whitespace. Because hasvaryheader() failed to strip that whitespace, a response with a Vary: header (note the trailing space) was not recognized as containing the wildcard, causing it to be stored and potentially served from the cache when it should not have been.

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

Thanks to Navid Rezazadeh for the report.

Affected supported versions

Django main Django 6.1 (currently at alpha status) Django 6.0 Django 5.2

Resolution

Patches to resolve the issue have been applied to Django's main, 6.1 (currently at alpha status), 6.0, and 5.2 branches. The patches may be obtained from the following changesets.

CVE-2026-6873: Signed cookie salt namespace collision in django.http.HttpRequest.getsignedcookie

On the main branch On the 6.1 branch On the 6.0 branch On the 5.2 branch

CVE-2026-7666: Potential unencrypted email transmission via STARTTLS in the SMTP backend

On the main branch On the 6.1 branch On the 6.0 branch On the 5.2 branch

CVE-2026-8404: Potential exposure of private data via case-sensitive Cache-Control directives in UpdateCacheMiddleware

On the main branch On the 6.1 branch On the 6.0 branch On the 5.2 branch

CVE-2026-35193: Potential exposure of private data via missing Vary: Authorization in UpdateCacheMiddleware

On the main branch On the 6.1 branch On the 6.0 branch On the 5.2 branch

CVE-2026-48587: Potential exposure of private data via whitespace padding in Vary header

On the main branch On the 6.1 branch On the 6.0 branch On the 5.2 branch

The following releases have been issued

Django 6.0.6 (tarball | checksums) Django 5.2.15 (tarball | checksums)

The PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E

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.

An issue was discovered in Django 6.0 before 6.0.6 and 5.2 before 5.2.15. django.http.HttpRequest.getsignedcookie in Django uses a non-injective salt derivation (concatenating the cookie name and salt argument), which allows a remote attacker to use a cookie in a context different from the one where it was signed, via distinct (name, salt) pairs that produce the same concatenation. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Peng Zhou for reporting this issue.

Announce: https://www.djangoproject.com/weblog/2026/mar/03/security-releases/

CVE JSON Record for CVE-2026-25673: https://www.cve.org/CVERecord?id=CVE-2026-25673

CVE JSON Record for CVE-2026-25674: https://www.cve.org/CVERecord?id=CVE-2026-25674

In accordance with our security release policy <https://docs.djangoproject.com/en/stable/internals/security/>, the Django team is issuing releases for Django 6.0.3 <https://docs.djangoproject.com/en/stable/releases/6.0.3/>, Django 5.2.12 <https://docs.djangoproject.com/en/stable/releases/5.2.12/>, and Django 4.2.29 <https://docs.djangoproject.com/en/stable/releases/4.2.29/ . These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

CVE-2026-25673: Potential denial-of-service vulnerability in URLField via Unicode normalization on Windows ==============================================================================================================

The django.forms.URLField form field's topython() method used urllib.parse.urlsplit() to determine whether to prepend a URL scheme to the submitted value. On Windows, urlsplit() performs NFKC normalization (unicodedata.normalize), which can be disproportionately slow for large inputs containing certain characters.

URLField.topython() now uses a simplified scheme detection, avoiding Unicode normalization entirely and deferring URL validation to the appropriate layers. As a result, while leading and trailing whitespace is still stripped by default, characters such as newlines, tabs, and other control characters within the value are no longer handled by URLField.topython(). When using the default URLValidator, these values will continue to raise ValidationError during validation, but if you rely on custom validators, ensure they do not depend on the previous behavior of URLField.topython().

This issue has severity "moderate" according to the Django Security Policy.

Thanks to Seokchan Yoon for the report.

CVE-2026-25674: Potential incorrect permissions on newly created file system objects ====================================================================================

Django's file-system storage and file-based cache backends used the process umask to control permissions when creating directories. In multi-threaded environments, one thread's temporary umask change can affect other threads' file and directory creation, resulting in file system objects being created with unintended permissions.

Django now applies the requested permissions via os.chmod() after os.mkdir(), removing the dependency on the process-wide umask.

This issue has severity "low" according to the Django Security Policy.

Thanks to Tarek Nakkouch for the report.

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-2026-25673: Potential denial-of-service vulnerability in URLField via Unicode normalization on Windows --------------------------------------------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/951ffb3832cd83ba672c1e3deae2bda128eb9cca On the 6.0 branch < https://github.com/django/django/commit/b1444d9acf43db9de96e0da2b4737ad56af0eb76 On the 5.2 branch < https://github.com/django/django/commit/4d3c184686626d224d9a87451410ecf802b41f7c On the 4.2 branch < https://github.com/django/django/commit/b3e8ec8cc310489fe80174b14b11edb970d682ea CVE-2026-25674: Potential incorrect permissions on newly created file system objects ------------------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/019e44f67a8dace67b786e2818938c8691132988 On the 6.0 branch < https://github.com/django/django/commit/264d5c70ef3281a8869cb2ad45a3a52d5adbe790 On the 5.2 branch < https://github.com/django/django/commit/b07ed2a1e445efde54fc64cb8c37e0f4f7fe53e5 On the 4.2 branch < https://github.com/django/django/commit/54b50bf7d6dcbf02d4c01f853627cc9299d4934d The following releases have been issued =======================================

Django 6.0.3 (download Django 6.0.3 <https://www.djangoproject.com/download/6.0.3/tarball/> | 6.0.3 checksums <https://www.djangoproject.com/download/6.0.3/checksum/>) Django 5.2.12 (download Django 5.2.12 <https://www.djangoproject.com/download/5.2.12/tarball/> | 5.2.12 checksums <https://www.djangoproject.com/download/5.2.12/checksum/>) Django 4.2.29 (download Django 4.2.29 <https://www.djangoproject.com/download/4.2.29/tarball/> | 4.2.29 checksums <https://www.djangoproject.com/download/4.2.29/checksum/>)

The PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E < https://github.com/nessita.gpg>

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 <https://www.djangoproject.com/security/> for further information.

An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29. Race condition in file-system storage and file-based cache backends in Django allows an attacker to cause file system objects to be created with incorrect permissions via concurrent requests, where one thread's temporary umask change affects other threads in multi-threaded environments. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Tarek Nakkouch for reporting this issue.

An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29. URLField.topython() in Django calls urllib.parse.urlsplit(), which performs NFKC normalization on Windows that is disproportionately slow for certain Unicode characters, allowing a remote attacker to cause denial of service via large URL inputs containing these characters. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Seokchan Yoon for reporting this issue.

An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28. FilteredRelation is 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(), valueslist(), and alias(). Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Solomon Kebede for reporting this issue.

An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.

.QuerySet.orderby() is subject to SQL injection in column aliases containing periods when the same alias is, using a suitably crafted dictionary, with dictionary expansion, used in FilteredRelation. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.

Django would like to thank Solomon Kebede for reporting this issue.

An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.

FilteredRelation is 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(), valueslist(), and alias(). Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.

Django would like to thank Solomon Kebede for reporting this issue.

An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.

django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True) and the truncatecharshtml and truncatewordshtml template filters allow a remote attacker to cause a potential denial-of-service via crafted inputs containing a large number of unmatched HTML end tags. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.

Django would like to thank Seokchan Yoon for reporting this issue.

An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.

Raster lookups on RasterField (only implemented on PostGIS) allows remote attackers to inject SQL via the band index parameter. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.

Django would like to thank Tarek Nakkouch for reporting this issue.

An issue was discovered in 5.2 before 5.2.9, 5.1 before 5.1.15, and 4.2 before 4.2.27. Algorithmic complexity in django.core.serializers.xmlserializer.getInnerText() allows a remote attacker to cause a potential denial-of-service attack triggering CPU and memory exhaustion via specially crafted XML input processed by the XML Deserializer. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Seokchan Yoon for reporting this issue.

USN-4381-1 fixed several vulnerabilities in Django. This update provides the corresponding update for Ubuntu 14.04 ESM. Original advisory details: Dan Palmer discovered that Django incorrectly validated memcached cache keys. A remote attacker could possibly use this issue to cause a denial of service and obtain sensitive information. (CVE-2020-13254) Jon Dufresne discovered that Django incorrectly encoded query parameters for the admin ForeignKeyRawIdWidget. A remote attacker could possibly use this issue to perform XSS attacks. (CVE-2020-13596)

Norbert Szetei discovered that Django incorrectly handled the GIS functions and aggregates on Oracle. A remote attacker could possibly use this issue to perform an SQL injection attack.

Simon Charette discovered that Django incorrectly handled input in the PostgreSQL module. A remote attacker could possibly use this to perform SQL injection attacks.

Simon Charette discovered that the password reset functionality in Django used a Unicode case insensitive query to retrieve accounts associated with an email address. An attacker could possibly use this to obtain password reset tokens and hijack accounts.

It was discovered that Django incorrectly handled certain inputs. An attacker could possibly use this issue to execute arbitrary code. This issue only affected Ubuntu 18.04 LTS, Ubuntu 18.10 and Ubuntu 19.04. (CVE-2019-12308) Gavin Wahl discovered that Django incorrectly handled HTTP detection when used behind a reverse-proxy. Client requests made via HTTP would cause incorrect API results and would not be redirected to HTTPS, contrary to expectations. (CVE-2019-12781)

It was discovered that Django incorrectly handled the default 404 page. A remote attacker could use this issue to spoof content using a malicious URL.

Andreas Hug discovered that Django contained an open redirect in CommonMiddleware. A remote attacker could possibly use this issue to perform phishing attacks.

James Davis discovered that Django incorrectly handled certain template filters. A remote attacker could possibly use this issue to cause Django to consume resources, resulting in a denial of service.

It was discovered that Django incorrectly handled certain requests. An attacker could possibly use this to access sensitive information. (CVE-2017-12794, CVE-2018-6188)