* 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 ``to_python()`` 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.to_python()`` 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.to_python()``. 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.to_python()``. 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 ``[email protected]``, 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.
