Ihre Anwendung läuft. Sie tut das seit Jahren, verlässlich, jeden Tag. Genau deshalb hat niemand einen Grund gesehen, die darunterliegende PHP-Version anzufassen. Und genau hier liegt das Missverständnis: Ein System, das stabil läuft, beweist, dass Ihre Fachlogik funktioniert. Über die Sicherheit der Plattform, auf der diese Logik läuft, sagt es nichts aus. Eine veraltete PHP-Version ist kein kosmetisches Problem, sondern ein akutes, wachsendes Sicherheitsrisiko, das mit jedem Monat größer wird.
Was bedeutet das veraltete PHP Version Risiko konkret?
Jede PHP-Version hat einen festen Lebenszyklus. Nach dem Release gibt es rund zwei Jahre aktiven Support mit Bugfixes, danach ein weiteres Jahr, in dem ausschließlich noch Sicherheitslücken geschlossen werden. Danach ist Schluss: keine Sicherheitsupdates mehr, für keine noch so kritische Lücke.
Das ist der Kern des Problems. Wenn nach dem End-of-Life einer Version eine schwerwiegende Schwachstelle im PHP-Core oder in einer Standard-Extension entdeckt wird, gibt es dafür offiziell keinen Patch mehr. Die Lücke bleibt offen. Für immer. PHP 7.4 etwa hat seinen Security-Support Ende 2022 verloren, PHP 8.0 Ende 2023. Wer heute noch darauf produktiv ist, betreibt eine Software, die per Definition ungepatcht ist.
Warum ist eine bekannte Lücke gefährlicher als eine unbekannte?
Eine ausgelaufene PHP-Version ist deshalb so kritisch, weil die Schwachstellen öffentlich dokumentiert sind. Sobald eine CVE veröffentlicht wird, kennt sie jeder — auch automatisierte Scanner, die das Internet permanent nach angreifbaren Servern absuchen. Ein Angreifer muss nichts mehr selbst finden. Er liest die Versionsnummer aus, gleicht sie gegen eine Liste bekannter Exploits ab und hat einen fertigen Angriffsweg. Bei aktiv gepflegten Versionen schließt ein Update dieses Fenster innerhalb von Tagen. Bei einer EOL-Version bleibt es dauerhaft offen.
Es geht nicht nur um PHP selbst
Das Risiko beschränkt sich nicht auf den PHP-Core. Eine alte PHP-Version zieht ein ganzes Ökosystem mit sich, das ebenfalls veraltet:
- Framework-Versionen: Ein Symfony 4 oder ein Laravel 6 läuft nicht auf aktuellem PHP. Solange Sie auf alter PHP-Version festhängen, hängen Sie auch auf einer Framework-Version fest, die selbst längst keine Sicherheitsupdates mehr bekommt.
- Composer-Abhängigkeiten: Bibliotheken für Authentifizierung, PDF-Erzeugung, Bildverarbeitung oder Payment lassen sich nicht mehr aktualisieren, weil neue Versionen modernes PHP voraussetzen. Sie sitzen auf alten, teils verwundbaren Paketen fest.
- Verlust moderner Schutzmechanismen: Neuere PHP-Versionen bringen härtere Defaults mit, etwa bei der Passwort-Hashing-API, bei sicherer Zufallszahlenerzeugung oder bei strengeren Typprüfungen, die ganze Klassen von Fehlern verhindern.
Sicherheit ist hier eine Kette. Die veraltete PHP-Version ist das erste Glied, das alle anderen blockiert. Sie können den Composer-Stack nicht modernisieren, ohne vorher die Plattform zu heben.
Aber wir haben doch eine Firewall — reicht das nicht?
Nein. Eine Web Application Firewall und Netzwerksegmentierung sind sinnvoll, aber sie sind eine zweite Verteidigungslinie, kein Ersatz für einen gepatchten Applikationsserver. Eine WAF filtert bekannte Angriffsmuster, doch sie kennt Ihre Anwendung nicht im Detail und lässt sich bei gezielten Angriffen umgehen. Verlassen Sie sich allein auf die Firewall, setzen Sie darauf, dass ein Angreifer den einen offenen Weg nie findet. Das ist keine Sicherheitsstrategie, das ist Hoffnung.
Dazu kommt ein praktischer Punkt, der oft vergessen wird: Compliance. Wer personenbezogene Daten verarbeitet, ist nach DSGVO zu Maßnahmen nach dem Stand der Technik verpflichtet. Ein PHP-Stack ohne Sicherheitsupdates ist im Schadensfall schwer zu verteidigen. Auch PCI-DSS im Zahlungsverkehr fordert explizit zeitnahes Patching. Eine EOL-Version ist hier ein handfestes Prüfungsrisiko, nicht nur ein technisches.
Die gute Nachricht: Das Problem ist selten die Fachlogik
Wenn ich zu einer solchen Anwendung dazukomme, höre ich oft den Reflex, jetzt müsse alles neu gebaut werden. In den allermeisten Fällen ist das die teuerste und riskanteste aller Optionen. Sie werfen dabei genau das weg, was funktioniert: die über Jahre gereifte, im echten Betrieb erprobte Geschäftslogik. Diese Logik ist Ihr Kapital, kein Altlast.
Das eigentliche Problem sitzt fast nie in der Fachlogik, sondern im Code drumherum — in veralteten Aufrufen, in Funktionen, die eine neue PHP-Version nicht mehr kennt, in Annahmen über Typen, die inzwischen strenger geprüft werden. Das ist überschaubar und, viel wichtiger, es ist mechanisch angehbar.
Wie hebt man eine PHP-Version, ohne alles neu zu schreiben?
Eine Migration läuft in der Praxis nicht als großer Sprung, sondern schrittweise:
- Bestandsaufnahme: Welche PHP-Version, welche Extensions, welche Composer-Pakete laufen aktuell? Was ist deprecated, was fällt bei einem Sprung weg?
- Testnetz aufspannen: Bevor Sie irgendetwas migrieren, brauchen Sie zumindest grobe automatisierte Tests für die kritischen Pfade. Sie sind Ihr Sicherheitsnetz.
- Statische Analyse: Werkzeuge wie PHPStan oder Rector finden Inkompatibilitäten automatisch und können viele davon sogar direkt umschreiben. Das nimmt einem Versionssprung einen großen Teil der Handarbeit ab.
- Version für Version: Von 7.4 nicht direkt auf 8.4, sondern in Etappen. Jede Etappe ist ein prüfbarer, kleiner Schritt mit klarem Ergebnis.
Ehrlich betrachtet: Was Sie jetzt tun sollten
Prüfen Sie zuerst schlicht, welche PHP-Version im Produktivbetrieb läuft — oft weiß das im Team niemand aus dem Kopf. Gleichen Sie diese Version gegen den offiziellen PHP-Lebenszyklus ab. Steht sie außerhalb des Security-Supports, ist das kein Thema für das nächste Quartal, sondern eines mit Priorität. Nicht in Panik, sondern in einem geplanten, getesteten Vorgehen.
Und noch einmal, weil es der wichtigste Punkt ist: Ihr laufendes System ist kein Kandidat für die Tonne. Es ist der Beweis, dass Ihre Logik trägt. Es braucht kein neues Fundament, es braucht einen sicheren Boden unter dem bestehenden. Genau bei dieser Art von Modernisierung — Version heben, Abhängigkeiten aktualisieren, ohne die bewährte Fachlogik zu opfern — unterstützt LegacyWerk, wenn Sie das nicht allein stemmen möchten.
