„Läuft aus“ ist eigentlich untertrieben. PHP 5 ist seit Jahren vollständig am Ende seines Lebenszyklus – die letzte Version der 5er-Reihe bekommt seit Anfang 2019 keine Sicherheitsupdates mehr. Wer heute noch eine Anwendung auf PHP 5 oder gar PHP 4 betreibt, läuft auf einer Software, für die seit über sieben Jahren keine offiziellen Patches mehr erscheinen.
Das Tückische daran: Die Anwendung läuft trotzdem. Sie tut, was sie soll. Und genau deshalb bleibt das Risiko oft unsichtbar, bis etwas passiert.
Wo PHP heute steht
Um einzuordnen, wie weit PHP 5 zurückliegt, hilft ein Blick auf den aktuellen Stand. PHP folgt einem festen Rhythmus: Jedes Jahr erscheint eine neue Version, die dann zwei Jahre vollen Support und zwei weitere Jahre nur noch Sicherheitspatches erhält, bevor sie ihr Lebensende erreicht.
Aktiv unterstützt sind im Jahr 2026 nur noch die Versionen 8.2 bis 8.5, wobei die jüngste, PHP 8.5, Ende 2025 erschienen ist. Alles bis einschließlich PHP 8.1 hat das Lebensende bereits hinter sich – PHP 8.1 fiel zum Jahreswechsel 2025/2026 aus dem Support. Zwischen einem unterstützten PHP 8.4 und einem PHP 5 aus den frühen Zweitausendern liegen nicht nur Versionsnummern, sondern ein grundlegend anderes Verständnis von Sicherheit, Objektorientierung und Performance.
Die konkreten Risiken alter PHP-Anwendungen
Offene Sicherheitslücken, die niemand mehr schließt
Jede nach dem Support-Ende entdeckte Schwachstelle in PHP 5 bleibt offen. Es gibt keinen offiziellen Patch mehr. Angreifer wissen das, und alte PHP-Anwendungen gehören zu den dankbarsten Zielen im Netz – nicht, weil sie besonders interessant sind, sondern weil sie verlässlich verwundbar sind.
Die typischen Altlasten der frühen PHP-Jahre
Alte PHP-Anwendungen tragen Muster mit sich, die heute als Sicherheitsproblem gelten. register_globals machte URL- und Formularparameter direkt zu Variablen im Code – bequem, aber ein offenes Tor. magic_quotes sollte Eingaben absichern, hat aber vor allem Daten verunreinigt und falsche Sicherheit vermittelt. Beides ist in modernem PHP längst entfernt, lebt in alten Codebasen aber weiter.
SQL-Injection durch zusammengebaute Abfragen
In PHP-5-Code werden Datenbankabfragen oft als Strings aus Benutzereingaben zusammengesetzt. Das ist die klassische Einladung zur SQL-Injection. Die alten mysql_*-Funktionen, die diesen Stil prägten, wurden mit PHP 7 ganz aus der Sprache entfernt – ein Grund, warum sich alte Anwendungen nicht einfach auf neue PHP-Versionen heben lassen.
Compliance und Haftung
Eine Anwendung ohne Sicherheitsupdates ist schwer mit Datenschutz- und Compliance-Anforderungen vereinbar. Wer personenbezogene Daten auf einer seit Jahren ungepatchten Plattform verarbeitet, trägt ein Risiko, das im Ernstfall auch ein rechtliches wird.
Warum man PHP 5 nicht einfach „hochziehen“ kann
Ein naheliegender Gedanke: einfach die PHP-Version auf dem Server erhöhen. In der Praxis scheitert das fast immer. PHP 7 und 8 haben mit Altlasten aufgeräumt – entfernte Funktionen, geänderte Verhaltensweisen, strengere Typprüfung. Eine PHP-5-Anwendung, die man unverändert auf PHP 8 stellt, wirft in aller Regel sofort Fehler oder verhält sich subtil falsch.
Der Sprung über mehrere Hauptversionen ist deshalb kein Update, sondern eine Migration. Und wenn man ohnehin migriert, lohnt es sich, gleich richtig zu modernisieren, statt nur die Versionsnummer zu retten.
Der Weg auf einen unterstützten Stand
Wir migrieren alte PHP-Anwendungen auf Laravel mit aktuellem PHP und ein React-Frontend. Dabei werden die God-Klassen aufgelöst, die in gewachsenem Code fast immer existieren, die magic_quotes-Altlasten in den Daten bereinigt und die Datenbankzugriffe auf sichere, parametrisierte Abfragen umgestellt. Aus „läuft noch irgendwie“ wird eine Anwendung, die wieder Updates bekommt und die Prüfungen besteht, die alter Code reihenweise nicht bestanden hätte.
Wie das konkret abläuft, beschreiben wir auf der Seite zur PHP-Migration und im Detail unter PHP 5 zu Laravel migrieren.
Was Sie jetzt tun können
Der erste Schritt: Im Code-Assessment bestimmen wir, auf welcher PHP-Version Ihre Anwendung wirklich läuft, welche Altlasten sie trägt und wie der Weg auf einen sicheren Stand aussieht.
Automatisiertes Code-Assessment anfragen →
Häufige Fragen
Unsere PHP-5-Anwendung wurde nie angegriffen. Ist das nicht Beweis genug, dass sie sicher ist? Nein. Dass bisher nichts passiert ist, sagt nichts über die offenen Lücken aus. Es ist eher Glück als Sicherheit.
Reicht es, nur den Server abzusichern? Das verschiebt das Problem, löst es aber nicht. Die Schwachstellen liegen in der Anwendung und in der ungepatchten PHP-Version selbst.
Wie lange dauert so eine Migration? Das hängt vom Zustand des Codes ab. Eine belastbare Einschätzung gibt das Assessment.
Quellen
- PHP.net – Supported Versions / Release-Policy: https://www.php.net/supported-versions.php
- endoflife.date – PHP-Versionsübersicht: https://endoflife.date/php
Dies ist ein informativer Beitrag und keine Rechtsberatung.