Django's admin auto-linked URLField values without validating the scheme — a stored javascript: value rendered as a live link. Fixed in 6.0.8 and 5.2.17.

DjangoCRM ships with its Django SECRETKEY hardcoded directly in the committed webcrm/settings.py rather than read from an environment variable. Since this key is used for session signing, CSRF token generation, and password reset tokens, anyone who reads the public repository can forge valid session cookies (including for the superadmin account), forge CSRF tokens, and forge password reset tokens, achieving full account takeover.

An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. GeoDjango spatial lookups optimistically parse the right-hand-side value as a raster by passing it to the django.contrib.gis.gdal.GDALRaster constructor. Any value used in a spatial lookup against a GeometryField or RasterField reaches this constructor, including untrusted input, for example a spatial-field filter submitted through the Django admin changelist query string by a staff user with view permission. A dict, or a str holding its JSON representation, is opened in write mode regardless of the constructor's write=False default, allowing a file with an attacker-chosen name and contents to be written through a file-backed GDAL driver. Any other str is treated as a datasource, allowing an outbound network request through a GDAL virtual filesystem handler. Writing a file to a location later imported by the application can result in remote code execution. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Bence Nagy, localhost-detect, and kimchunbok for reporting this issue.

An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. GeoDjango's django.contrib.gis.geos.GEOSGeometry is subject to a potential denial-of-service when parsing deeply nested GEOMETRYCOLLECTION objects supplied as well-known text (WKT), well-known binary (WKB), or hex-encoded WKB, which triggers unbounded recursion and a segmentation fault in the underlying GEOS library. Spatial field lookups and the django.contrib.gis.forms.GeometryField form field are also affected. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Andrew MacPherson and kimchunbok for reporting this issue.

An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. django.utils.translation.checkforlanguage() is subject to a potential denial-of-service attack when given many distinct, very long language codes, which are retained as keys in an in-memory cache and consume process memory. Such codes reach the function through the django.views.i18n.setlanguage() view, which is not routed by default. The consumed memory is bounded, since request data is limited by the DATAUPLOADMAXMEMORYSIZE setting (default 2.5 MB) and the cache holds a fixed maximum number of entries. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Jaeyoung Jang for reporting this issue.

An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. GeoDjango spatial lookups optimistically parse the right-hand-side value as a raster by passing it to the django.contrib.gis.gdal.GDALRaster constructor. Any value used in a spatial lookup against a GeometryField or RasterField reaches this constructor, including untrusted input, for example a spatial-field filter submitted through the Django admin changelist query string by a staff user with view permission. A dict, or a str holding its JSON representation, is opened in write mode regardless of the constructor's write=False default, allowing a file with an attacker-chosen name and contents to be written through a file-backed GDAL driver. Any other str is treated as a datasource, allowing an outbound network request through a GDAL virtual filesystem handler. Writing a file to a location later imported by the application can result in remote code execution. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Bence Nagy, localhost-detect, and kimchunbok for reporting this issue.

Announce: https://www.djangoproject.com/weblog/2026/jul/07/security-releases/

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

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

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

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

CVE-2026-48588: Potential exposure of private data via cached Set-Cookie response

django.middleware.cache.UpdateCacheMiddleware and django.views.decorators.cache.cachepage avoided caching responses that set a cookie while varying on Cookie only when the incoming request contained no cookies at all. When the request already carried an unrelated cookie (such as a language or theme preference cookie), the protection did not apply, allowing a response that sets a session or other sensitive cookie to be stored in Django's shared cache.

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

Thanks to Chris Whyland for the report.

CVE-2026-53877: Heap buffer over-read in GDALRaster

When django.contrib.gis.gdal.GDALRaster was instantiated with a bytes object representing a raster file, the vsibuffer property could over-read the allocated buffer by approximately 32 bytes. This could result in information disclosure of adjacent heap memory or, in rare cases, a segmentation fault. Only rasters stored in GDAL's virtual filesystem were affected.

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

Thanks to Bence Nagy for the report.

CVE-2026-53878: Header injection possibility since DomainNameValidator accepted newlines in input

django.core.validators.DomainNameValidator accepted newlines in domain names. If such values were included in HTTP responses, header injection attacks were possible. Django itself wasn't vulnerable because HttpResponse prohibits newlines in HTTP headers.

The vulnerability only affected uses of DomainNameValidator outside Django form fields, as CharField strips newlines by default.

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

Thanks to Bence Nagy for the report.

Affected supported versions

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

Resolution

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

CVE-2026-48588: Potential exposure of private data via cached Set-Cookie response

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

CVE-2026-53877: Heap buffer over-read in GDALRaster

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

CVE-2026-53878: Header injection possibility since DomainNameValidator accepted newlines in input

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.7 (tarball | checksums) Django 5.2.16 (tarball | checksums)

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.

An issue was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16. DomainNameValidator does not prohibit newlines in domain names (unless used via a form field, since CharField strips newlines). If an application uses values with newlines in an HTTP response, header injection can occur. Django itself is unaffected because HttpResponse prohibits newlines in HTTP headers. 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 Bence Nagy for reporting this issue.

An issue was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16. django.contrib.gis.gdal.GDALRaster over-reads its in-memory buffer when constructed from a bytes object, which can disclose adjacent memory or cause service degradation via a potential segmentation fault when the vsibuffer property is accessed. 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 Bence Nagy for reporting this issue.

An issue was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16. UpdateCacheMiddleware and the cachepage() decorator cache responses that vary on cookies when the incoming request carries unrelated cookies, which allows remote attackers to read private data from the shared cache. 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 Chris Whyland for reporting this issue.

daphne before 4.2.2 did not pass maxFramePayloadSize or maxMessagePayloadSize to Autobahn's WebSocketServerFactory. Because Autobahn defaults both values to 0 (unlimited), an unauthenticated remote attacker could send arbitrarily large WebSocket messages or frames, causing excessive memory consumption and a denial of service.

An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6. django.utils.cache.hasvaryheader() in Django does not strip leading or trailing whitespace from Vary response header values before comparison, which allows remote attackers to read cached responses via requests to URLs whose responses contain whitespace-padded Vary header values. 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 Navid Rezazadeh for reporting this issue.

An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6. django.middleware.cache.UpdateCacheMiddleware in Django does not match Cache-Control response directives case-insensitively, which allows remote attackers to read responses that were incorrectly cached because their Cache-Control directives used uppercase or mixed-case values. 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 Ahmed Badawe for reporting this issue.

Announce: https://www.djangoproject.com/weblog/2026/may/05/security-releases/

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

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

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

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

CVE-2026-5766: Potential denial-of-service vulnerability in ASGI requests via file upload limit bypass

ASGI requests with a missing or understated Content-Length header could bypass the FILEUPLOADMAXMEMORYSIZE limit, potentially loading large files into memory and causing service degradation.

As a reminder, Django expects a limit to be configured at the web server level rather than solely relying on FILEUPLOADMAXMEMORYSIZE.

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

This issue was originally highlighted by Kyle Agronick in Trac. Thanks to Jacob Walls for following up and reporting it.

CVE-2026-35192: Session fixation via public cached pages and SESSIONSAVEEVERYREQUEST

Response headers did not vary on cookies if a session was not modified, but SESSIONSAVEEVERYREQUEST was True. A remote attacker could steal a user's session after that user visits a cached public page.

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

CVE-2026-6907: Potential exposure of private data due to incorrect handling of Vary: in UpdateCacheMiddleware

Previously, django.middleware.cache.UpdateCacheMiddleware would erroneously cache requests where the Vary header contained an asterisk (''). This could lead to private data being stored and served.

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

Thanks to Ahmad Sadeddin for the report.

Affected supported versions

Django main Django 6.0 Django 5.2

Resolution

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

CVE-2026-5766: Potential denial-of-service vulnerability in ASGI requests via file upload limit bypass

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

CVE-2026-35192: Session fixation via public cached pages and SESSIONSAVEEVERYREQUEST

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

CVE-2026-6907: Potential exposure of private data due to incorrect handling of Vary: in UpdateCacheMiddleware

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

The following releases have been issued

Django 6.0.5 (tarball | checksums) Django 5.2.14 (tarball | checksums)

The PGP key ID used for this release is Sarah Boyce: 3955B19851EA96EF

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 6.0 before 6.0.5 and 5.2 before 5.2.14. Response headers do not vary on cookies if a session is not modified, but SESSIONSAVEEVERYREQUEST is True. A remote attacker can steal a user's session after that user visits a cached public page. 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 Cantina for reporting this issue.

An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14. django.middleware.cache.UpdateCacheMiddleware erroneously caches requests where the Vary header contained an asterisk (''). This can lead to private data being stored and served. 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 Ahmad Sadeddin for reporting this issue.

An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14. ASGI requests with a missing or understated Content-Length header can bypass the FILEUPLOADMAXMEMORYSIZE limit, potentially loading large files into memory and causing service degradation. As a reminder, Django expects a limit to be configured at the web server level rather than solely relying on FILEUPLOADMAXMEMORYSIZE. 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 Kyle Agronick for reporting this issue.

Announce: https://www.djangoproject.com/weblog/2026/apr/07/security-releases/

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

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

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

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

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

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

Django 4.2 has reached the end of extended support ================================================== Note that with this release, Django 4.2 has reached the end of extended support. All Django 4.2 users are encouraged to upgrade <https://docs.djangoproject.com/en/dev/howto/upgrade-version/> to Django 5.2 or later to continue receiving fixes for security issues.

See the downloads page <https://www.djangoproject.com/download/#supported-versions> for a table of supported versions and the future release schedule.

CVE-2026-3902: ASGI header spoofing via underscore/hyphen conflation ====================================================================

ASGIRequest normalizes header names following WSGI conventions, mapping hyphens to underscores. As a result, even in configurations where reverse proxies carefully strip security-sensitive headers named with hyphens, such a header could be spoofed by supplying a header named with underscores.

Under WSGI, it is the responsibility of the server or proxy to avoid ambiguous mappings. (Django's runserver was patched in CVE-2015-0219.) But under ASGI, there is not the same uniform expectation, even if many proxies protect against this under default configuration (including nginx via underscoresinheaders off;).

Headers containing underscores are now ignored by ASGIRequest, matching the behavior of Daphne, the reference server for ASGI.

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

Thanks to Tarek Nakkouch for the report.

CVE-2026-4277: Privilege abuse in GenericInlineModelAdmin =============================================================

Add permissions on inline model instances were not validated on submission of forged POST data in GenericInlineModelAdmin.

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

Thanks to N05ec@LZU-DSLab for the report.

CVE-2026-4292: Privilege abuse in ModelAdmin.listeditable ==============================================================

Admin changelist forms using ModelAdmin.listeditable incorrectly allowed new instances to be created via forged POST data.

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

CVE-2026-33033: Potential denial-of-service vulnerability in MultiPartParser via base64-encoded file upload ===============================================================================================================

When using django.http.multipartparser.MultiPartParser, multipart uploads with Content-Transfer-Encoding: base64 that include excessive whitespace may trigger repeated memory copying, potentially degrading performance.

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

Thanks to Seokchan Yoon for the report.

CVE-2026-33034: Potential denial-of-service vulnerability in ASGI requests via memory upload limit bypass =========================================================================================================

ASGI requests with a missing or understated Content-Length header could bypass the DATAUPLOADMAXMEMORYSIZE limit when reading HttpRequest.body, potentially loading an unbounded request body into memory and causing service degradation.

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

Thanks to Superior 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-3902: ASGI header spoofing via underscore/hyphen conflation --------------------------------------------------------------------

On the main branch <https://github.com/django/django/commit/caf90a971f09323775ed0cacf94eadaf39d040e0> On the 6.0 branch <https://github.com/django/django/commit/a623c3982857e80324448f85c7faf9a6710330ef> On the 5.2 branch <https://github.com/django/django/commit/1cc2a7612f97c109b92415fc11ba9bd0501852e0> On the 4.2 branch <https://github.com/django/django/commit/4412731aa64d62a6dd7edae79e0c15b72666d7ca>

CVE-2026-4277: Privilege abuse in GenericInlineModelAdmin -------------------------------------------------------------

On the main branch <https://github.com/django/django/commit/ef8b25dcc06d158683a5623ce406d561638f4073> On the 6.0 branch <https://github.com/django/django/commit/08a752c1cd8f378b4c64d96c319da23726df6ed3> On the 5.2 branch <https://github.com/django/django/commit/60ffa957c427e10a2eb0fc80d1674a8a8ccc30b0> On the 4.2 branch <https://github.com/django/django/commit/051f3909e820360bbe84a21350e82f4961e3d917>

CVE-2026-4292: Privilege abuse in ModelAdmin.listeditable --------------------------------------------------------------

On the main branch <https://github.com/django/django/commit/6afe7ce93964f56e33a29d477c269436f9b60cbf> On the 6.0 branch <https://github.com/django/django/commit/428c48f358c5a0ed5ca2834fb721d615eb2b0e11> On the 5.2 branch <https://github.com/django/django/commit/397c22048244db2cd4bb78f570e6c72a3967bf36> On the 4.2 branch <https://github.com/django/django/commit/abfe1a1c57a57cfaf6dd4a0571c029401a0fe743>

CVE-2026-33033: Potential denial-of-service vulnerability in MultiPartParser via base64-encoded file upload ---------------------------------------------------------------------------------------------------------------

On the main branch <https://github.com/django/django/commit/7e9885f99cee771b51692fadc5592bdbf19641aa> On the 6.0 branch <https://github.com/django/django/commit/0910af60468216c856dfbcac1177372c225deb76> On the 5.2 branch <https://github.com/django/django/commit/0b467893bdde69a2d23034338e76021a1e4f4322> On the 4.2 branch <https://github.com/django/django/commit/f13c20f81b56108ac477213fa5ada2524b5e5c98>

CVE-2026-33034: Potential denial-of-service vulnerability in ASGI requests via memory upload limit bypass ---------------------------------------------------------------------------------------------------------

On the main branch <https://github.com/django/django/commit/953c238058c0ce387a1a41cb491bfc1875d73ad0> On the 6.0 branch <https://github.com/django/django/commit/393dbc53e848876fdba92fbf02e10ee6a6eace6b> On the 5.2 branch <https://github.com/django/django/commit/49e1e2b548999a35a025f9682598946bda9e9921> On the 4.2 branch <https://github.com/django/django/commit/ed4dfda62718a0bb644b80ac8b1d3099861f2295>

The following releases have been issued =======================================

Django 6.0.4 (download Django 6.0.4 <https://www.djangoproject.com/download/6.0.4/tarball/> | 6.0.4 checksums <https://www.djangoproject.com/download/6.0.4/checksum/>) Django 5.2.13 (download Django 5.2.13 <https://www.djangoproject.com/download/5.2.13/tarball/> | 5.2.13 checksums <https://www.djangoproject.com/download/5.2.13/checksum/>) Django 4.2.30 (download Django 4.2.30 <https://www.djangoproject.com/download/4.2.30/tarball/> | 4.2.30 checksums <https://www.djangoproject.com/download/4.2.30/checksum/>)

The PGP key ID used for this release is Jacob Walls: 131403F4D16D8DC7 <https://github.com/jacobtylerwalls.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.

Summary

A Cross-site Scripting (XSS) vulnerability exists in the {% attrs %} template tag of the slippers Django package. When a context variable containing untrusted data is passed to {% attrs %}, the value is interpolated into an HTML attribute string without escaping, allowing an attacker to break out of the attribute context and inject arbitrary HTML or JavaScript into the rendered page.

Vulnerability details

Root cause

AttrsNode is a custom Node subclass registered via register.tag(). Unlike register.simpletag(), which automatically applies conditionalescape() when autoescape is on, custom Node.render() methods receive no automatic escaping and are fully responsible for sanitising their output. attrstring() fails to do this:

python def attrstring(key: str, value: Any): if isinstance(value, bool): return key if value else "" key = key.replace("", "-") return f'{key}="{value}"' # value is not escaped

Attack scenario

Given a template that uses {% attrs %} with a user-supplied value:

django {% load slippers %} <input {% attrs type placeholder %}>

python render(request, "search.html", {"placeholder": request.GET.get("q", "")})

An attacker crafting a request with q=" onmouseover="alert(document.cookie)" x=" produces:

html <input type="text" placeholder="" onmouseover="alert(document.cookie)" x="">

Impact

Any template that passes values derived from user input, database content, or other untrusted sources to {% attrs %} is vulnerable. Successful exploitation can lead to session hijacking, credential theft, arbitrary actions on behalf of the victim, and page defacement.

Remediation

Replace the f-string in attrstring() with formathtml(), which escapes both key and value:

python from django.utils.html import formathtml

def attrstring(key: str, value: Any): if isinstance(value, bool): return key if value else "" key = key.replace("", "-") return formathtml('{}="{}"', key, value)

Until a patch is available, sanitise untrusted values before passing them to {% attrs %}, for example with django.utils.html.escape() in the view layer.

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.

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.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 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. 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. ASGIRequest allows a remote attacker to cause a potential denial-of-service via a crafted request with multiple duplicate headers. 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 Jiyong Yang for reporting this issue.

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

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

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

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

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

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

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

In accordance with our security release policy <https://docs.djangoproject.com/en/dev/internals/security/>, the Django team is issuing releases for Django 6.0.2 <https://docs.djangoproject.com/en/dev/releases/6.0.2/>, Django 5.2.11 <https://docs.djangoproject.com/en/dev/releases/5.2.11/>, and Django 4.2.28 <https://docs.djangoproject.com/en/dev/releases/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 modwsgi authentication handler =================================================================================================

The django.contrib.auth.handlers.modwsgi.checkpassword() function for authentication via modwsgi 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 truncatecharshtml and truncatewordshtml 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(), valueslist(), 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.orderby and FilteredRelation =========================================================================================

QuerySet.orderby() 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 modwsgi authentication handler -------------------------------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/3eb814e02a4c336866d4189fa0c24fd1875863ed On the 6.0 branch < https://github.com/django/django/commit/d72cc3be3be0bbebdcaea5a8c8106b4d6f2a32bd On the 5.2 branch < https://github.com/django/django/commit/184e38ab0a061c365f5775676a074796d8abd02f On the 4.2 branch < https://github.com/django/django/commit/6dc23508f3395e1254c315084c7334ef81c4c09a CVE-2025-14550: Potential denial-of-service vulnerability via repeated headers when using ASGI ----------------------------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/eb22e1d6d643360e952609ef562c139a100ea4eb On the 6.0 branch < https://github.com/django/django/commit/972dbdd4f7f69e9c405e6fe12a1b90e4713c1611 On the 5.2 branch < https://github.com/django/django/commit/1ba90069c12836db46981bdf75b0e661db5849ce On the 4.2 branch < https://github.com/django/django/commit/f578acc8c54530fffabd52d2db654c8669b011af CVE-2026-1207: Potential SQL injection via raster lookups on PostGIS --------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/81aa5292967cd09319c45fe2c1a525ce7b6684d8 On the 6.0 branch < https://github.com/django/django/commit/8f77e7301174834573614ae90e1826fdf27f8a24 On the 5.2 branch < https://github.com/django/django/commit/17a1d64a58ef24c0c3b78d66d86f5415075f18f0 On the 4.2 branch < https://github.com/django/django/commit/a14363102d98fa29b8cced578eb3a0fadaa5bcb7 CVE-2026-1285: Potential denial-of-service vulnerability in django.utils.text.Truncator HTML methods --------------------------------------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/a33540b3e20b5d759aa8b2e4b9ca0e8edd285344 On the 6.0 branch < https://github.com/django/django/commit/4b86ba51e486530db982341a23e53c7a1e1e6e71 On the 5.2 branch < https://github.com/django/django/commit/9f2ada875bbee62ac46032e38ddb22755d67ae5a On the 4.2 branch < https://github.com/django/django/commit/b40cfc6052ced26dcd8166a58ea6f841d0d2cac8 CVE-2026-1287: Potential SQL injection in column aliases via control characters -------------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/e891a84c7ef9962bfcc3b4685690219542f86a22 On the 6.0 branch < https://github.com/django/django/commit/0c0f5c2178c01ada5410cd53b4b207bf7858b952 On the 5.2 branch < https://github.com/django/django/commit/3e68ccdc11c127758745ddf0b4954990b14892bc On the 4.2 branch < https://github.com/django/django/commit/f75f8f3597e1ce351d5ac08b6ba7ebd9dadd9b5d CVE-2026-1312: Potential SQL injection via QuerySet.orderby and FilteredRelation -----------------------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/69065ca869b0970dff8fdd8fafb390bf8b3bf222 On the 6.0 branch < https://github.com/django/django/commit/15e70cb83e6f7a9a2a2f651f30b28b5cb20febeb On the 5.2 branch < https://github.com/django/django/commit/e863ee273c6553e9b6fa4960a17acb535851857b On the 4.2 branch < https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314 The following releases have been issued =======================================

Django 6.0.2 (download Django 6.0.2 <https://www.djangoproject.com/download/6.0.2/tarball/> | 6.0.2 checksums <https://www.djangoproject.com/download/6.0.2/checksum/>) Django 5.2.11 (download Django 5.2.11 <https://www.djangoproject.com/download/5.2.11/tarball/> | 5.2.11 checksums <https://www.djangoproject.com/download/5.2.11/checksum/>) Django 4.2.28 (download Django 4.2.28 <https://www.djangoproject.com/download/4.2.28/tarball/> | 4.2.28 checksums <https://www.djangoproject.com/download/4.2.28/checksum/>)

The PGP key ID used for this release is Jacob Walls: 131403F4D16D8DC7 < https://github.com/jacobtylerwalls.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.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.

ASGIRequest allows a remote attacker to cause a potential denial-of-service via a crafted request with multiple duplicate headers. 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 Jiyong Yang 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.

The django.contrib.auth.handlers.modwsgi.checkpassword() function for authentication via modwsgi allows remote attackers to enumerate users via a timing attack. 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 Stackered for reporting this issue.

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

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

Announce: https://www.djangoproject.com/weblog/2025/dec/02/security-releases/

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

CVE-2025-13372: Potential SQL injection in FilteredRelation column aliases on PostgreSQL ============================================================================================

FilteredRelation was subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the kwargs passed to QuerySet.annotate() or QuerySet.alias() on PostgreSQL.

Thanks to Stackered for the report.

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

CVE-2025-64460: Potential denial-of-service vulnerability in XML serializer text extraction ===========================================================================================

Algorithmic complexity in django.core.serializers.xmlserializer.getInnerText() allowed a remote attacker to cause a potential denial-of-service triggering CPU and memory exhaustion via specially crafted XML input submitted to a service that invokes XML Deserializer. The vulnerability resulted from repeated string concatenation while recursively collecting text nodes, which produced superlinear computation resulting in service degradation or outage.

Thanks to Seokchan Yoon (https://ch4n3.kr/) for the report.

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

Affected supported versions ===========================

Django main Django 6.0 (currently at release candidate status) Django 5.2 Django 5.1 Django 4.2

Resolution ==========

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

CVE-2025-13372: Potential SQL injection in FilteredRelation column aliases on PostgreSQL --------------------------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/5b90ca1e7591fa36fccf2d6dad67cf1477e6293e On the 6.0 branch < https://github.com/django/django/commit/56aea00c3c5e1aacf4ed05f8ee06c2e78f02cea0 On the 5.2 branch < https://github.com/django/django/commit/479415ce5249bcdebeb6570c72df2a87f45a7bbf On the 5.1 branch < https://github.com/django/django/commit/9c6a5bde24240382807d13bc3748d08444709355 On the 4.2 branch < https://github.com/django/django/commit/f997037b235f6b5c9e7c4a501491ec45f3400f3d CVE-2025-64460: Potential denial-of-service vulnerability in XML serializer text extraction -------------------------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/50efb718b31333051bc2dcb06911b8fa1358c98c On the 6.0 branch < https://github.com/django/django/commit/1dbd07a608e495a0c229edaaf84d58d8976313b5 On the 5.2 branch < https://github.com/django/django/commit/99e7d22f55497278d0bcb2e15e72ef532e62a31d On the 5.1 branch < https://github.com/django/django/commit/0db9ea4669312f1f4973e09f4bca06ab9c1ec74b On the 4.2 branch < https://github.com/django/django/commit/4d2b8803bebcdefd2b76e9e8fc528d5fddea93f0 The following releases have been issued =======================================

Django 5.2.9 (download Django 5.2.9 <https://www.djangoproject.com/download/5.2.9/tarball/> | 5.2.9 checksums <https://www.djangoproject.com/download/5.2.9/checksum/>) Django 5.1.15 (download Django 5.1.15 <https://www.djangoproject.com/download/5.1.15/tarball/> | 5.1.15 checksums <https://www.djangoproject.com/download/5.1.15/checksum/>) Django 4.2.27 (download Django 4.2.27 <https://www.djangoproject.com/download/4.2.27/tarball/> | 4.2.27 checksums <https://www.djangoproject.com/download/4.2.27/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.