Was sich am 7. April geändert hat

Link zu diesem Abschnitt

Das Django-Projekt pflegt immer nur seine aktuellen Versionen. Heute sind das 5.2 LTS (bis April 2028), 6.0 (bis April 2027) und 6.1 (bis Dezember 2027). Für alles Ältere gilt die Regel des Security Teams: Diese Versionen können von einer Lücke betroffen sein, untersucht und behoben wird das aber nicht mehr.

Seit dem Supportende hat Django 15 Sicherheitslücken veröffentlicht. Behoben wurden sie nur in 5.2, 6.0 und 6.1. Ob 4.2 von einer davon betroffen ist, prüft niemand mehr.

Django-Sicherheitsreleases seit dem Supportende von 4.2
ReleaseLückenSchweregrad
5. Mai 20263alle niedrig
3. Juni 20265alle niedrig
7. Juli 20263alle niedrig
4. August 202641 hoch (GeoDjango), 2 mittel (darunter XSS im Admin), 1 niedrig

Die Zahl allein macht Django nicht unsicherer. Laut Security Team sind viele Meldungen inzwischen Varianten bekannter Lücken, gefunden mit KI-Werkzeugen. Entscheidend ist, dass die Behebungen nur noch die unterstützten Versionen erreichen.

Auch die Pakete rund um Django sind weitergezogen. Diese unterstützen 4.2 in ihren aktuellen Versionen nicht mehr:

  • Django REST framework ab 3.18.0 (August 2026)
  • Wagtail ab 7.4 (Mai 2026)
  • django CMS ab 5.1 (Juli 2026)
  • django-debug-toolbar ab 7.0 (Juni 2026)
  • django-filter ab 25.2 (Oktober 2025)

Die Plattformen ziehen nach. Python 3.10, auf dem viele 4.2-Projekte laufen, erreicht im Oktober 2026 selbst das Ende seines Supports. Heroku entfernt Python 3.10 am 6. Januar 2027, AWS Lambda stellt die Laufzeit ab 31. Oktober 2026 schrittweise ein.

Selbsttest: Wie groß ist das Thema bei euch?

Link zu diesem Abschnitt

Diese sieben Fragen kannst du deinem Team oder deinem Hoster stellen, ohne selbst in den Code zu schauen. Jede Antwort verschiebt den Aufwand nach oben oder unten.

  1. Welche Django-Version läuft in Produktion? 4.2 ist der Ausgangspunkt dieses Artikels. Liegt die Version darunter, etwa bei 3.2, wird der Weg länger.
  2. Welche Python-Version? Django 5.2 braucht mindestens Python 3.10. Bei 3.8 oder 3.9 kommt zuerst ein Python-Upgrade, und auch 3.10 endet im Oktober 2026.
  3. Welche Datenbank in welcher Version? Django 5.2 setzt PostgreSQL 14 oder neuer voraus. Ein Datenbank-Upgrade ist ein eigener Schritt mit eigenem Risiko.
  4. Gibt es automatische Tests, und laufen sie bei jedem Deploy? Tests zeigen nach jedem Schritt, ob noch alles funktioniert. Ohne sie wird jede Änderung von Hand geprüft.
  5. Wie viele Fremdpakete stehen in den Abhängigkeiten, und wann wurden sie zuletzt aktualisiert? Meist blockiert nicht der eigene Code, sondern ein Paket, das niemand mehr pflegt.
  6. Wann war der letzte Deploy, und wie läuft er ab? Erst ein Deploy, der regelmäßig und automatisch läuft, macht ein Upgrade in kleinen Schritten möglich.
  7. Wer kennt den Code heute noch? Hat das Team gewechselt, beginnt das Upgrade mit einer Bestandsaufnahme.

Drei Wege

Link zu diesem Abschnitt

Upgrade auf Django 5.2 LTS

Der Weg, den das Django-Projekt selbst empfiehlt. 5.2 bekommt Sicherheitsupdates bis April 2028, und die Pakete rund um Django unterstützen es.

Wann das passt: Wenn die Anwendung noch Jahre laufen soll. Das ist bei den meisten der Fall.

Verlängerter Support gegen Gebühr

Anbieter wie HeroDevs oder TuxCare liefern weiter Sicherheitspatches für 4.2, zu Preisen auf Anfrage. Der Code bleibt, wie er ist. Die Pakete rund um Django bleiben aber auf ihrem alten Stand, und das Upgrade kommt später trotzdem.

Wann das passt: Als Überbrückung, wenn ein Upgrade in den nächsten Monaten nicht machbar ist, etwa während eines Audits oder vor einer Ablösung.

Bleiben und absichern

Weiterbetrieb mit Firewall-Regeln, abgeschalteten Funktionen und genauem Monitoring. Linux-Distributionen wie Ubuntu patchen ihr eigenes Django-Paket noch eine Weile. Das hilft aber nur, wenn Django über das Betriebssystem installiert ist und nicht über pip.

Wann das passt: Nur, wenn die Anwendung ohnehin bald abgeschaltet wird.

Warum 5.2 und nicht gleich 6.x

Link zu diesem Abschnitt

Django 6.0 und 6.1 brauchen Python 3.12 oder neuer. Django 5.2 läuft auf Python 3.10 bis 3.14. Damit lassen sich Django und Python getrennt aktualisieren, und das ist der sicherere Weg.

Die nächste LTS-Version, 6.2, erscheint im April 2027 und bekommt Updates bis April 2030. Ab 2028 veröffentlicht Django eine Version pro Jahr, jede mit drei Jahren Support. Wer heute auf 5.2 mit Python 3.12 oder neuer geht, hat den nächsten Schritt offen und keinen Zeitdruck.

Wovon der Aufwand abhängt

Link zu diesem Abschnitt

Für den Aufwand eines Django-Upgrades gibt es keine belastbaren veröffentlichten Zahlen. Er hängt an wenigen Faktoren, die sich für jedes Projekt vorab prüfen lassen:

  • Fremdpakete. Der häufigste Blocker. Selbst python.org musste auf ein einzelnes Paket warten, bevor der Umstieg auf 5.2 möglich war.
  • Python. Ein Sprung von 3.8 oder 3.9 heißt oft auch ein neues Basis-Image oder Betriebssystem.
  • Datenbank. PostgreSQL unter Version 14 muss vorher aktualisiert werden.
  • Tests. Je besser der Code abgedeckt ist, den das Upgrade berührt, desto kleiner die Schritte und desto geringer das Risiko.
  • Eigener Code. Zwischen 4.2 und 5.2 fallen einige Dinge weg: Zeitzonen sind jetzt Standard, Logout geht nur noch per POST, Dateispeicher werden über STORAGES konfiguriert, index_together und alte Passwort-Hasher sind entfernt. Wie oft der eigene Code sich darauf stützt, entscheidet über einen guten Teil der Stunden.

Ein Upgrade ohne Stillstand

Link zu diesem Abschnitt
  1. Bestandsaufnahme: Versionen, Pakete, Tests und Deployment erfassen, bevor sich etwas ändert.
  2. Absichern: Tests für die Stellen ergänzen, die das Upgrade berührt.
  3. Pakete: jedes Paket auf eine Version bringen, die 5.2 unterstützt, oder einen Ersatz finden.
  4. Schrittweise: 4.2, 5.0, 5.1, 5.2, auf jeder Stufe mit allen Warnungen behoben. Werkzeuge wie django-upgrade schreiben viele Änderungen automatisch um.
  5. Staging: jeden Schritt auf einer Umgebung mit produktionsnahen Daten prüfen.
  6. Rollout: jeder Schritt geht einzeln live, mit einem Weg zurück.