Noch auf PHP 8.1 oder älter? Das Risiko unsupporteter PHP-Versionen in 2026

Wenn Ihre Website oder Ihr internes System noch auf PHP 8.1 oder älter läuft, tragen Sie das Risiko einer unsupporteten PHP-Version schon jetzt, nicht erst irgendwann in der Zukunft. PHP 8.1 hat sein eigenes End of Life am 31. Dezember 2025 erreicht. PHP 8.0 bekam bereits im November 2023 keine Fixes mehr, PHP 7.4 davor, im November 2022. Keine dieser Versionen wird je wieder gepatcht, für keine Schwachstelle, egal wie schwerwiegend sie ist.

Viele Unternehmer erfahren das eher zufällig, meist von einem Entwickler, einer Hosting-Rechnung oder einem Sicherheitsfragebogen eines Kunden oder einer Versicherung. Dieser Beitrag soll dafür sorgen, dass Sie es nicht auf diese Weise herausfinden müssen.

Das Risiko unsupporteter PHP-Versionen, das niemand erklärt

Jede PHP-Version hat ein festes Zeitfenster. Für rund zwei Jahre gibt es sowohl Bugfixes als auch Sicherheitsfixes. Für weitere zwei Jahre gibt es nur noch Sicherheitsfixes. Danach endet der Support vollständig. Das PHP-Projekt patcht nichts mehr in einer End-of-Life-Version, egal wie schwerwiegend sich eine Schwachstelle später herausstellt.

Diese Unterscheidung ist wichtig, denn viele Unternehmer gehen davon aus, "alt" bedeute nur "langsamer" oder "weniger Funktionen". Das stimmt nicht. Eine neu entdeckte Schwachstelle in PHP 7.4, 8.0 oder 8.1 bleibt dort, dokumentiert in öffentlichen Schwachstellen-Datenbanken, solange Ihr System diese Version weiter betreibt. Niemand kommt, um sie zu beheben. Ihr Hosting-Anbieter kann keine Schwachstelle in der Sprache selbst beheben, nur in seiner eigenen Infrastruktur darum herum. Angreifer brauchen keine fortgeschrittenen Fähigkeiten, um eine veröffentlichte Schwachstelle ohne verfügbaren Fix zu finden und zu nutzen. Viele Angriffe heute sind automatisierte Scans, die gezielt nach genau solchen Zielen suchen.

Es taucht auch gern im ungünstigsten Moment auf: während einer Cyberversicherungs-Schadensmeldung, einer Compliance-Prüfung oder einem Sicherheitsfragebogen eines Kunden, der vor Vertragsunterschrift wissen will, was Sie einsetzen. "Wir liefen auf einer Version ohne Sicherheitssupport" ist nichts, was jemand erklären möchte, nachdem schon etwas schiefgegangen ist.

Die Hosting-Rechnung, über die niemand vorher spricht

Hier kommt der Teil, der selbst Leute überrascht, die ihre alte PHP-Version bereits kennen. Hosting-Anbieter unterstützen End-of-Life-PHP-Versionen nicht kostenlos weiter, und manche unterstützen sie gar nicht mehr.

Bei mehreren Hostern zeigen sich ähnliche Muster. Manche verschieben Kunden mit alten PHP-Versionen still in eine Legacy- oder Unmanaged-Stufe mit höherer Monatsgebühr, weil der Betrieb dieser Version weiterhin Zeit ihrer Techniker kostet, obwohl das Open-Source-Projekt längst weitergezogen ist. Manche bieten bezahlte Extended-Security-Patches genau für diese Situation an, was eine echte Option ist, wenn eine Brücke benötigt wird, aber mehr kostet, als aktuell zu bleiben gekostet hätte. Andere kündigen schlicht an, dass eine Version in ein paar Monaten nicht mehr auf ihrer Plattform angeboten wird, was aus einem geplanten Upgrade ein erzwungenes mit einer harten, nicht selbst gewählten Frist macht.

Das ist kein Grund zur Panik, aber ein Grund, herauszufinden, wo Sie stehen, bevor Ihr Hoster es Ihnen nach seinem eigenen Zeitplan sagt.

Herausfinden, was Sie tatsächlich einsetzen

Dafür muss keine Zeile Code angefasst werden. Ein paar Wege, um schnell eine klare Antwort zu bekommen:

Fragen Sie Ihren Hosting-Anbieter. Die meisten Control Panels, ob cPanel, Plesk oder das eigene Dashboard eines Managed Hosters, zeigen die PHP-Version irgendwo in den Konto- oder Servereinstellungen an, und der Support kann das meist innerhalb von Minuten per Chat oder E-Mail bestätigen.

Fragen Sie den Entwickler, die Agentur oder den Freelancer, der Ihre Website betreut. "Welche PHP-Version läuft bei uns, und wann hat sie ihr End of Life erreicht?" ist eine einzeilige Frage. Wie schnell und sicher sie beantwortet wird, sagt bereits etwas darüber, wie genau Ihr System tatsächlich betreut wird.

Prüfen Sie es selbst, wenn Ihre Seite auf WordPress läuft. Unter Werkzeuge, dann Website-Zustand, dann der Reiter Info, listet der Abschnitt Server die PHP-Version im Klartext.

Wenn keiner dieser Wege für Sie offensteht, dauert ein kurzes Gespräch mit einem unabhängigen Entwickler, der sich Ihren Server ansehen und Rückmeldung geben kann, weniger Zeit, als die meisten erwarten, und verpflichtet Sie zu nichts außer dieser Antwort.

Ein gestufter Upgrade-Pfad, keine Wochenend-Hektik

Der Umfang dieses Projekts hängt vollständig davon ab, was Sie einsetzen, und wer Ihnen eine Zahl nennt, bevor er Ihren tatsächlichen Code gesehen hat, rät nur. Was den Umfang zuverlässig beeinflusst: wie alt die Anwendung ist, wie viele Drittanbieter-Plugins oder -Bibliotheken sie nutzt, wie viel speziell für Ihr Unternehmen individuell entwickelt wurde, und ob eine automatisierte Testsuite existiert, um zu bestätigen, dass dabei nichts kaputtgeht.

Ein realistischer Weg sieht meist etwa so aus. Zunächst prüft jemand die aktuelle Codebasis und ihre Abhängigkeiten, um zu sehen, was tatsächlich mit einer neueren PHP-Version kompatibel ist und was neu geschrieben werden muss. Dann wird das Upgrade auf einer Kopie der Website oder Anwendung gebaut und getestet, nicht auf der Live-Umgebung, damit Probleme dort auftauchen, wo sie keine Kunden kosten. Automatisierte Werkzeuge wie Rector können einen erheblichen Teil der mechanischen Änderungen bei PHP-Upgrades übernehmen, was die manuelle Umschreibarbeit bei größeren Codebasen reduziert. Erst wenn diese Kopie sauber läuft, geht die Änderung in die Produktion, meist mit einem Rollback-Plan für den Fall, dass unter echtem Traffic etwas Unerwartetes auftaucht.

Wir haben eine technischere Schritt-für-Schritt-Anleitung zu genau diesem Prozess geschrieben, falls Sie die technischen Details hinter jedem Schritt wissen möchten.

Eine Entscheidung lohnt sich früh: welche Version das Ziel ist. Direkt auf PHP 8.3 oder 8.4 zu springen, statt bei einer Version zu stoppen, die selbst bald ihr eigenes End of Life erreicht, bringt für etwa denselben Aufwand deutlich mehr Vorlauf. PHP 8.2 befindet sich gerade in seiner letzten Phase, der Sicherheitssupport endet am 31. Dezember 2026, es als langfristiges Ziel zu behandeln würde also bedeuten, bald wieder ein weiteres Upgrade planen zu müssen. PHP 8.3 hat Sicherheitssupport bis Dezember 2027, PHP 8.4 bis Dezember 2028.

Wenn es nicht sofort erledigt werden kann

Manchmal ist die ehrliche Antwort, dass die Arbeit nicht in diesem Quartal stattfindet, sei es, weil erst ein Entwickler gefunden werden muss, die Codebasis größer ausgefallen ist als erwartet, oder weil erst Budget freigegeben werden muss. Wenn das Ihre Situation ist, reduzieren ein paar Maßnahmen in der Zwischenzeit das Risiko.

Fragen Sie Ihren Hoster direkt nach Extended-Security-Support-Optionen, die auf derselben Quelle basieren, die das PHP-Projekt veröffentlicht hat, bevor die Version End of Life erreichte. Das ist als Brücke gedacht, nicht als dauerhafte Lösung, schließt aber die Lücke bei bekannten Schwachstellen, während das eigentliche Upgrade geplant wird.

Reduzieren Sie die Angriffsfläche. Eine Web Application Firewall, strengere Zugriffsregeln auf Serverebene und Admin-Bereiche, die nicht offen im Internet erreichbar sind, senken alle die Wahrscheinlichkeit, dass eine bekannte Schwachstelle in Ihrer PHP-Version gefunden und gegen Sie genutzt wird, bevor das Upgrade kommt.

Am wichtigsten: Setzen Sie ein echtes Datum, keine vage Absicht. "Wir kümmern uns darum" ist der Weg, auf dem ein Unternehmen jahrelang statt monatelang unsupportete Software betreibt. Ein fester Starttermin, auch wenn er erst ein paar Wochen entfernt liegt, macht daraus ein geplantes Projekt mit einem Verantwortlichen statt einer Hintergrundsorge.

Wo Sie anfangen

Finden Sie diese Woche heraus, welche PHP-Version Sie aktuell einsetzen, falls Sie es nicht bereits wissen, und holen Sie sich eine realistische Einschätzung, was ein Upgrade für Ihr spezifisches System bedeutet, bevor eine Hosting-Ankündigung oder ein Sicherheitsvorfall jemand anderem die Entscheidung nach dessen Zeitplan aufzwingt. Ein kurzer Tech-Stack-Review oder ein fokussiertes Legacy-System-Upgrade kann beides meist innerhalb weniger Tage beantworten.

Wenn Sie eine zweite Meinung dazu möchten, wo Sie stehen, oder Hilfe, das Upgrade ordentlich fertigzustellen, melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io. Wir haben genug alte PHP-Anwendungen durch diesen Übergang begleitet, um zu wissen, welche Abkürzungen sicher sind und welche sechs Monate später zurückschlagen.