Django 6.1.2, 6.0.9 und 5.2.18 schließen vier Sicherheitslücken, eine mit inkompatibler Änderung
Das Django-Projekt hat am 6. Oktober die Sicherheitsversionen 6.1.2, 6.0.9 und 5.2.18 veröffentlicht und bittet alle Nutzer, so bald wie möglich zu aktualisieren. Die Patches betreffen die Zweige main, 6.1, 6.0 und 5.2.

Die vier Lücken.
- CVE-2026-84429, mittel.
django.utils.http.parse_header_parameters()hatte quadratische Laufzeit bei Werten mit vielen Trennzeichen in einem Parameter in Anführungszeichen. Eine nicht authentifizierte Anfrage konnte das über Header wie Accept oder Content-Type erreichen, etwa überHttpRequest.accepts(); das Längenlimit pro Aufruf begrenzte wiederholte Header nicht. Die Funktion nutzt jetzt Pythonsemail.message.Message, ungewöhnliche Header-Werte können daher anders geparst werden. - CVE-2026-77050, niedrig.
get_supported_language_variant()speicherte Sprachcodes im Cache, bevor ihre Länge begrenzt wurde; viele lange Codes konnten viel Speicher belegen. Codes über 500 Zeichen werden jetzt vorher abgewiesen oder gekürzt. - CVE-2026-87890, Request-Fälschung über Geo-Abfragen. GIS-Abfragen akzeptierten Rasterwerte als rohe Bytes; diese konnten ein VRT-Dokument mit externer Quelle enthalten und GDAL Netzwerkanfragen im Namen des Django-Prozesses auslösen lassen. Raster-Bytes müssen jetzt in
GDALRasterverpackt werden – laut Projekt eine inkompatible Änderung; gültige hexadezimale Geometrien bleiben erlaubt. - CVE-2026-87975, Model-Formsets. Gefälschte POST-Daten konnten Objekte außerhalb des Formset-Querysets löschen oder über reine Bearbeitungs-Formsets Objekte anlegen, wenn der Primärschlüssel über das Formular setzbar war (OneToOneField oder natürlicher bzw. UUID-Schlüssel unter den Feldern).
Was zu tun ist. Auf die Version des eigenen Zweigs aktualisieren. Code, der Raster-Bytes an Geo-Abfragen übergibt, braucht vor dem Update den GDALRaster-Wrapper.
Primärquelle
Django Weblog
https://www.djangoproject.com/weblog/2026/oct/06/security-releasesGeschrieben von Victoria Shinder.