PHP 5.6: seit 2018 ohne Sicherheitsupdates. Was beim Sprung auf PHP 8 bricht und wie der Weg aussieht

PHP 5.6 erschien im August 2014 und bekam als letzte Version der 5er-Reihe eine verlängerte Pflege bis Ende 2018. Seit dem 31. Dezember 2018 gibt es keine Sicherheitsupdates mehr, das letzte Release war 5.6.40 im Januar 2019. Wer heute noch darauf läuft, hat jede seitdem gefundene Lücke im Interpreter offen, einschließlich der beiden kritischen vom 21. Oktober 2026, für die es nur Fixes ab PHP 8.2 gab.

Wo PHP 5.6 heute steht

Anwendungen auf 5.6 sind meist zwischen 2010 und 2016 entstanden: Eigenentwicklungen ohne Framework, frühe Shops, Portale auf einem selbstgebauten Unterbau, Fachanwendungen in Verwaltungen und Mittelstand. Sie laufen noch, weil ihre Fachlogik funktioniert und niemand sie anfassen will. Drei Dinge haben sich seit 2018 geändert:

• Hoster schalten ab. Die großen deutschen Anbieter haben 5.6 aus dem Standardangebot genommen oder berechnen Aufschläge. Die Abschaltung kommt per Mail mit Frist, meist an die Rechnungsadresse.
• Bibliotheken sind weg. Zahlungsanbieter-SDKs, Mail-APIs, PDF-Bibliotheken: Die aktuellen Versionen setzen PHP 8.1 oder höher voraus. Irgendwann stellt ein Dienst seine alte API ab, und dann ist die Frist nicht mehr vom Hoster.
• Nachweispflichten. Wer Kartenzahlungen abwickelt oder personenbezogene Daten verarbeitet, kann mit einem Interpreter von 2019 "Stand der Technik" nicht mehr behaupten. Cyber-Versicherer lesen die Bedingungen im Schadensfall genau.

Was beim Upgrade von 5.6 auf PHP 8 bricht

Der Abstand von 5.6 zu 8.4 ist der größte, den es im PHP-Umfeld gibt. Das meiste davon ist bekannt und mechanisch, einiges findet man erst im Betrieb.

• Die mysql-Erweiterung (mysql_connect, mysql_query) wurde mit PHP 7.0 entfernt. In 5.6-Anwendungen ist sie fast immer an hunderten Stellen im Einsatz, oft ohne Prepared Statements. Wie der Umstieg auf mysqli oder PDO abläuft, haben wir ausführlich beschrieben.
• ereg, split und Verwandte sind seit 7.0 weg, mcrypt seit 7.2. Beide finden sich in alten Login- und Verschlüsselungsroutinen.
• PHP-4-Konstruktoren (eine Methode, die so heißt wie die Klasse) werden seit 8.0 nicht mehr als Konstruktor erkannt. Die Klasse lädt, aber der Konstruktor läuft nie. Das bricht leise.
• each(), create_function() und __autoload() sind seit 8.0 entfernt. Die geschweifte Klammer für Zeichenketten-Offsets ($str{0}) ebenfalls.
• Vergleiche zwischen Text und Zahl funktionieren seit 8.0 anders: 0 == "abc" ist jetzt falsch. Alte Prüfungen auf Benutzereingaben kippen, ohne dass eine Fehlermeldung erscheint.
• Interne Funktionen werfen Fehler statt Warnungen. Ein null oder ein Array an der falschen Stelle führte in 5.6 zu einer Warnung im Log und lief weiter. In PHP 8 bricht die Anfrage ab.
• Nicht deklarierte Eigenschaften sind seit 8.2 als veraltet markiert. Alte Klassen, die Werte beliebig an $this hängen, produzieren erst Hinweise, in einer späteren Version Fehler.
• Die Umgebung. Smarty 2, PHPExcel, PEAR-Pakete, ein eigenes Framework von 2011, ein PHPMailer aus derselben Zeit. Jedes braucht einen Ersatz oder einen Patch, bevor PHP 8 überhaupt startet. Der Code selbst geht oft davon aus, dass register_globals und Magic Quotes noch irgendwo wirken, obwohl beides seit 5.4 weg ist.

Die vollständige Liste der Brüche zwischen den Versionen steht im Beitrag PHP 8 Breaking Changes. Für die Suche nach entfernten Funktionen im eigenen Code gibt es eine Anleitung mit Werkzeugen.

Der Weg von 5.6 auf PHP 8.4

Wir gehen nicht über PHP 7. Der Zwischenschritt ist ein zweites Projekt mit denselben Vorarbeiten und ohne eigenen Nutzen. Die Reihenfolge, die funktioniert:

1. Bestandsaufnahme. Welche Funktionen und Erweiterungen sind im Einsatz, welche Bibliotheken, wie viel Code ist überhaupt noch erreichbar. Dafür reicht eine Kopie des Codes und ein Datenbankabbild, die Produktion wird nicht angefasst.
2. Sicherheitsnetz. Tests um die Abläufe, deren Ausfall Geld kostet: Bestellung, Rechnung, Export, Login. Nicht schön, aber ausreichend, um Verhaltensänderungen zu sehen.
3. Mechanische Umbauten mit Rector. Entfernte Funktionen, Konstruktoren, Offsets, Typ-Vergleiche. Was Rector leistet und wo es aufhört, steht im eigenen Beitrag.
4. Bibliotheken ersetzen. Jede tote Abhängigkeit bekommt einen aktuellen Ersatz mit derselben Schnittstelle, damit der Rest des Codes nicht mitwandert.
5. Umschalten in einer Randzeit, mit Rückweg. Die alte Version bleibt bereit, bis die ersten Wochen Betrieb ohne Auffälligkeit gelaufen sind.

Einen vollständigen Praxisleitfaden gibt es unter PHP 5.6 auf PHP 8 migrieren. Was ein solches Projekt kostet, hängt an Codeumfang, Testlage und Abhängigkeiten; die Pakete dafür stehen unten.

Für wen das nicht passt

Eine Anwendung, die in den nächsten zwölf Monaten durch Standardsoftware abgelöst wird, braucht keine Migration, sondern einen sicheren Weiterbetrieb bis zur Ablösung: abgeschotteter Server, kein direkter Zugang aus dem Internet, Backups geprüft. Das sagen wir im kostenlosen Kurz-Check, wenn es so ist.