Ce mail provient de l'extérieur, restons vigilants

=====================================================================


                            CERT-Renater

                Note d'Information No. 2026/VULN822
_____________________________________________________________________

DATE                : 05/08/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running Django versions prior to 6.0.8,
                                        5.2.17.
 
=====================================================================
https://www.djangoproject.com/weblog/2026/aug/04/security-releases/
_____________________________________________________________________


Django security releases issued: 6.0.8 and 5.2.17
Posted by Natalia Bidart on 4 août 2026

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


CVE-2026-15307: Server-side file-write and request forgery via spatial
lookups

Spatial lookups allowed str and dict lookup values to be passed to
GDALRaster when they represented rasters. Depending on the raster
driver, this could write a file to disk (in some cases enabling remote
code execution) or issue a network request as the Django process user.
Because the admin changelist permits filtering via
ModelAdmin.lookup_allowed(), the flaw was reachable by staff users with
view permissions on any registered model containing a spatial field.

The following types are now disallowed by spatial lookups:

    dict
    A str that is not a valid GEOSGeometry, e.g. a serialized dictionary

This is a backward incompatible change. As a reminder, all untrusted user
input should be validated before use. For that reason, assignments to
model fields are unaffected and still accept these input types.

For guidance on how to keep using these types in spatial lookups, on
validating untrusted input, and on further security considerations,
see the raster security considerations documentation.

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

Thanks to Bence Nagy, localhost-detect, and kimchunbok_ for the report.


CVE-2026-15337: Potential denial-of-service vulnerability in check_for_language()

django.utils.translation.check_for_language() was subject to a potential
denial-of-service attack when checking many distinct, very long language
codes. Each code was used as a key in an in-memory cache, consuming
process memory.

The language value reaches this function through the
django.views.i18n.set_language() view (not active by default) from POST
data. Since request data is limited by DATA_UPLOAD_MAX_MEMORY_SIZE and
the cache is configured to store a maximum number of entries, the memory
that could be consumed was bounded.

To mitigate this vulnerability, language codes longer than 500 characters
are now rejected before the cached lookup.

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

Thanks to Jaeyoung Jang for the report.


CVE-2026-15830: Potential denial-of-service vulnerability via nested
geometry collections

GEOSGeometry was subject to a potential denial-of-service attack when
provided deeply nested GEOMETRYCOLLECTION objects, leading to a segmentation
fault in GEOS. A maximum depth of 198 GEOMETRYCOLLECTIONs is now enforced
for the well-known text (WKT) format, and a maximum number of 198
GEOMETRYCOLLECTIONs in total (breadth and depth) is enforced for well-known
binary (WKB).

Lookups against spatial fields and the GeometryField form field were also
affected.

The limit can be customized through the new max_geom_collections argument,
available on GEOSGeometry, the form field, and the model field. The limit is
not applied to GeoJSON inputs, as they were parsed by GDAL and are not
affected.

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

Thanks to Andrew MacPherson and kimchunbok_ for the report.


CVE-2026-15920: Potential cross-site scripting via URLField values in the
admin

The admin renders URLField values as clickable links on changelist views and
read-only fields. The link was generated without validating the value as a
safe URL, so a stored value using a potentially dangerous scheme was
rendered as a link.

URLField values shown via display_for_field are now validated using
URLValidator before a link is rendered, and displayed as plain text if
validation is failed.

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

Thanks to Egor Saltykov (misop00p / ansjdnakjdnajkd) for the report.


Affected supported versions

    Django main
    Django 6.1 (currently at release candidate status)
    Django 6.0
    Django 5.2

Resolution

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


CVE-2026-15307: Server-side file-write and request forgery via spatial lookups

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

CVE-2026-15337: Potential denial-of-service vulnerability in check_for_language()

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

CVE-2026-15830: Potential denial-of-service vulnerability via nested geometry collections

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

CVE-2026-15920: Potential cross-site scripting via URLField values in the admin

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


=========================================================

+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================