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

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


                            CERT-Renater

                Note d'Information No. 2026/VULN977
_____________________________________________________________________

DATE                : 07/10/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running Django versions prior to 6.1.2,
                                    6.0.9, 5.2.18.
  
====================================================================
https://www.djangoproject.com/weblog/2026/oct/06/security-releases/
_____________________________________________________________________


Django security releases issued: 6.1.2, 6.0.9, and 5.2.18
Posted by Sarah Boyce on 6 octobre 2026

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


CVE-2026-77050: Potential denial-of-service vulnerability in
get_supported_language_variant()

django.utils.translation.get_supported_language_variant() was subject
to a potential denial-of-service attack when processing many distinct,
very long language codes. Language codes were used as keys in an
in-memory cache before their length was limited, potentially consuming
excessive process memory.

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

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

Thanks to Gleb Lizunov for the report.


CVE-2026-84429: Potential denial-of-service vulnerability in HTTP
header parsing

django.utils.http.parse_header_parameters() was subject to a potential
denial-of-service attack due to quadratic time complexity when parsing
a value with many separators inside a quoted parameter. An
unauthenticated request could reach this parsing through headers such
as Accept or Content-Type, for instance via the content negotiation
performed by HttpRequest.accepts(). The per-call length limit does not
bound the combined size of repeated headers.

The undocumented django.utils.http.parse_header_parameters() function
now uses Python's email.message.Message for parsing. As a result,
parsing of some malformed or unusual header values may differ, for
example, RFC 2231 values with a missing encoding are now decoded.

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

Thanks to Jisung Chae for the report.


CVE-2026-87890: Potential request forgery via spatial lookup byte
values

Spatial lookups accepted raster values provided as bytes without
requiring them to be explicitly wrapped in
django.contrib.gis.gdal.GDALRaster. Although these values were
opened through GDAL's in-memory virtual filesystem, they could
contain a VRT document referencing an external raster source. This
could cause GDAL to issue network requests as the Django process
user while preparing the lookup.

This issue could be exploited by applications that passed
attacker-controlled bytes directly to a spatial lookup. It was
overlooked in the fix for CVE-2026-15307.

To mitigate this issue, raster values provided as bytes must now
be wrapped in GDALRaster before being used in spatial lookups.
Byte values representing valid hexadecimal geometries remain
accepted.

This is a backward incompatible change. As a reminder, all
untrusted user input should be validated before use.

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

Thanks to sicksec for the report.


CVE-2026-87975: Privilege abuse in model formsets with editable
primary keys

Model formsets incorrectly allowed forged POST data to either delete
instances outside the limiting queryset or create instances via
edit-only formsets when the model's primary key could be set through 
the form, such as with: a OneToOneField (or parent link used as the
primary key of an inline formset's model), or a natural or UUID
primary key included in the form's fields. Models using the default
BigAutoField primary key were not affected.

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

Thanks to Seonggwon Yoon for the report.


Affected supported versions

    Django main
    Django 6.1
    Django 6.0
    Django 5.2


Resolution

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


CVE-2026-77050: Potential denial-of-service vulnerability in
get_supported_language_variant()

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

CVE-2026-84429: Potential denial-of-service vulnerability in HTTP
header parsing

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

CVE-2026-87890: Potential request forgery via spatial lookup byte
values

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

CVE-2026-87975: Privilege abuse in model formsets with editable
primary keys

    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.1.2 (tarball | checksums)
    Django 6.0.9 (tarball | checksums)
    Django 5.2.18 (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.


=========================================================
+ 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 +
=========================================================