Django 6.1.3, 6.0.10 und 5.2.19 beheben sechs Lücken, darunter zwei SSRF-Wege in GeoDjango
Victoria Shinder1 Min. LesezeitDas Django-Team hat die Sicherheitsversionen 6.1.3, 6.0.10 und 5.2.19 veröffentlicht, mit Patches für die Zweige main, 6.1, 6.0 und 5.2. Sie beheben sechs Probleme. Als mittel eingestuft ist CVE-2026-111362, eine Server-Side Request Forgery in GeoDjango: GeoJSON-Geometrien konnten ein Koordinatenreferenzsystem per URL angeben, GDAL löst solche URLs weiterhin auf, und jeder Pfad, der eine Geometrie aus Nutzereingaben erzeugte, konnte als Django-Prozess eine Netzwerkanfrage stellen oder eine Datei lesen. Räumliche Abfragen, das Formularfeld GeometryField und GEOSGeometry weisen solche Verweise nun zurück; die Werkzeuge DataSource und LayerMapping für vertrauenswürdige Daten akzeptieren sie weiter.
Ein zweiter SSRF-Weg, CVE-2026-114582, lief über String-Eingaben an SpatialReference, die GDAL ebenfalls als URL oder Datei auflöste. Django schaltet beim Parsen solcher Strings ab GDAL 3.9 Netzwerk- und Dateizugriff ab und lehnt DICT:-Verweise auf allen Versionen ab. Vollen Schutz gibt es erst mit GDAL 3.9; eine neue Systemprüfung, gis.W001, warnt bei älterem GDAL.
Die übrigen vier gelten als niedrig. UpdateCacheMiddleware und cache_page() erzeugten denselben Cache-Schlüssel für eine Anfrage ohne einen im Vary genannten Header und eine mit leerem Header, sodass eine zwischengespeicherte Antwort beim falschen Nutzer landen konnte (CVE-2026-113593); die Schlüssel unterscheiden nun beides, wie RFC 9111 verlangt. Base64-kodierte Multipart-Uploads konnten unabhängig von FILE_UPLOAD_MAX_MEMORY_SIZE vollständig im Speicher landen (CVE-2026-108147). GIS-Formular-Widgets schrieben ungültige Werte unmaskiert ins Log (CVE-2026-111211). Und Admin-Nutzer mit reinem Leserecht sahen bei manchen eigenen Benutzermodellen den vollständigen Passwort-Hash (CVE-2026-113733).
Das Team rät allen Nutzern zu einem raschen Update.
Was das bedeutet
Der Cache-Fix ändert das Verhalten beim Deployment: Antworten, die unter den alten Schlüsseln für Anfragen ohne Vary-Header gespeichert wurden, passen nicht mehr und werden neu zwischengespeichert. GeoDjango-Seiten sollten ihre GDAL-Version prüfen, denn unter 3.9 ist der SpatialReference-Fix nur teilweise wirksam.