.svg)
Das Wichtigste in Kürze
- PHP 8.2 erhält nach dem 31. Dezember 2026 keine Sicherheitsupdates mehr vom PHP-Projekt. PHP 8.1 ist bereits seit dem 31. Dezember 2025 ohne Support, PHP 8.3 folgt am 31. Dezember 2027.
- Wie wenig ein End of Life (EOL) im Ernstfall schützt, zeigte PHP2Shell im Oktober 2026: Offizielle Fixes gab es nur für 8.2 bis 8.5. Für PHP 7.4 bis 8.1 veröffentlichte das PHP-Projekt lediglich Quellcode-Backports, ältere Versionen erhielten keinen Fix.
- Laut einer ShiftPress-Auswertung von 54.743 Websites in Deutschland, Österreich und der Schweiz liefen 21 Prozent der Gemeinde-Websites mit sichtbarer PHP-Version noch auf PHP 8.1 oder älter. Bei bekannten .de-, .at- und .ch-Websites waren es 26 Prozent.
- Unter ISO 27001:2022 betrifft veraltete Software mindestens die Controls A.8.8, A.5.9 und A.8.32 sowie die Risikobehandlung nach Abschnitt 6.1.3. Ein Auditor erwartet entweder einen Upgrade-Plan mit Terminen oder eine dokumentierte, befristete Risikoakzeptanz.
- Wer jetzt upgradet, sollte auf PHP 8.4 oder 8.5 wechseln. Ein Umstieg auf 8.3 verschiebt dasselbe Problem nur um zwölf Monate.
PHP 8.2 End of Life ist kein Datum, das nur Entwickler betrifft. Ab dem 1. Januar 2027 schließt das PHP-Projekt in diesem Versionszweig keine Sicherheitslücken mehr, auch keine kritischen. Für Unternehmen mit einem ISMS nach ISO 27001 oder mit Pflichten unter NIS2 wird jede verbliebene PHP-8.2-Installation damit zu einer Frage, die im nächsten Audit gestellt wird: Wussten Sie davon, wie haben Sie das Risiko bewertet und was haben Sie entschieden?
Dieser Beitrag richtet sich an IT-Leitungen, CISOs, Informationssicherheitsbeauftragte und Compliance-Teams im Mittelstand. Er zeigt, welche PHP-Versionen wann aus dem Support fallen, welche Optionen Sie haben und welche Nachweise ein Auditor sehen will. Was die jüngste kritische Lücke technisch bedeutete und welche Sofortmaßnahmen nötig waren, beschreibt unser Beitrag zu PHP2Shell und den Folgen für ISO 27001 und NIS2.
Was PHP 8.2 End of Life konkret bedeutet
End of Life heißt: Das PHP-Projekt veröffentlicht für diesen Versionszweig keine Updates mehr, weder für Fehler noch für Sicherheitslücken. Jeder Zweig erhält zwei Jahre aktiven Support und danach zwei weitere Jahre ausschließlich Korrekturen für kritische Sicherheitsprobleme. Nach insgesamt vier Jahren ist Schluss.
PHP 8.2 erschien am 8. Dezember 2022. Der aktive Support endete am 31. Dezember 2024, seitdem gibt es nur noch Sicherheitsupdates. Mit dem 31. Dezember 2026 enden auch diese.
PHP2Shell als Generalprobe
Was das praktisch heißt, zeigte PHP2Shell. Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Notfall-Updates für zwei kritische Lücken im Interpreter, CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 nach CVSS v4.0 bewertet. Angreifer konnten darüber ohne Anmeldung Code auf Webservern ausführen.
Offizielle Releases gab es nur für die unterstützten Zweige: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 7.4, 8.0 und 8.1 stellte das PHP-Projekt lediglich minimale Quellcode-Backports bereit, ohne offizielles Release. Wer diese Versionen betrieb, musste den Patch selbst einbauen oder auf seine Linux-Distribution, seinen Hoster oder einen LTS-Anbieter warten. Für noch ältere Versionen gab es überhaupt keinen Fix.
Ein verbreiteter Irrtum lautet, dass bei einer wirklich kritischen Lücke schon jemand einen Patch nachliefern werde. PHP2Shell hat gezeigt, dass das für EOL-Versionen vom Zufall abhängt. Trifft eine vergleichbare Lücke PHP 8.2 im Februar 2027, gibt es kein PHP 8.2.36.
Welche PHP-Versionen wann aus dem Support fallen
Die folgende Übersicht zeigt die Termine aus der offiziellen Übersicht der unterstützten PHP-Versionen und der EOL-Liste des PHP-Projekts, Stand 3. November 2026.
| PHP-Version | Ende der Sicherheitsupdates | Status |
|---|---|---|
| PHP 8.5 | 31. Dezember 2029 | Aktiv unterstützt |
| PHP 8.4 | 31. Dezember 2028 | Aktiv unterstützt bis 31. Dezember 2026, danach nur Sicherheitsupdates |
| PHP 8.3 | 31. Dezember 2027 | Nur noch Sicherheitsupdates |
| PHP 8.2 | 31. Dezember 2026 | Nur noch Sicherheitsupdates, End of Life zum Jahresende |
| PHP 8.1 | 31. Dezember 2025 | End of Life |
| PHP 8.0 | 26. November 2023 | End of Life |
| PHP 7.4 | 28. November 2022 | End of Life |
Daraus folgt eine Empfehlung, die viele Teams übersehen: Wer jetzt von PHP 8.2 wegmigriert, sollte nicht auf 8.3 gehen. PHP 8.3 erreicht sein End of Life bereits am 31. Dezember 2027, der gesamte Aufwand stünde in zwölf Monaten erneut an. PHP 8.4 ist bis Ende 2028 abgedeckt, PHP 8.5 bis Ende 2029.
Wie verbreitet veraltete PHP-Versionen sind
Wie groß das Problem im deutschsprachigen Raum ist, zeigt eine Auswertung von ShiftPress, über die Borns IT- und Windows-Blog am 3. November 2026 berichtete. Untersucht wurden 54.743 Websites in Deutschland, Österreich und der Schweiz. Von den 1.071 Gemeinde-Websites, die ihre PHP-Version offen anzeigen, meldeten 21 Prozent PHP 8.1 oder älter. Bei bekannten Websites mit .de, .at und .ch lag der Anteil bei 26 Prozent, bei Hochschulen und Schulen bei 19 Prozent.
Diese Zahlen erfassen nur Versionen, die bereits heute ohne Support sind. Ab dem 1. Januar 2027 kommt jede Website auf PHP 8.2 hinzu.
Die Versionsnummer beweist nichts
Ein zweiter Irrtum betrifft die Versionsnummer. Viele Hoster und Linux-Distributionen spielen Sicherheitskorrekturen als Backport ein, ohne die angezeigte PHP-Version zu ändern. Eine alte Nummer bedeutet deshalb nicht automatisch, dass ein System ungeschützt ist. Umgekehrt beweist eine scheinbar aktuelle Nummer nicht, dass alle Patches eingespielt sind. Belastbar sind nur das Changelog des Pakets oder eine schriftliche Bestätigung des Hosters, welche CVEs behoben sind.
Warum veraltete Software ein Auditthema ist
ISO 27001 verbietet veraltete Software nicht. Die Norm verlangt aber, dass Sie wissen, wo sie läuft, das Risiko bewerten und eine dokumentierte Entscheidung treffen. Genau daran misst ein Auditor eine PHP-8.2-Installation im Jahr 2027.
Die relevanten Anforderungen aus ISO 27001:2022
A.8.8 Management technischer Schwachstellen verlangt, dass Sie Informationen über Schwachstellen rechtzeitig erhalten, Ihre Gefährdung bewerten und angemessene Maßnahmen ergreifen. Eine Komponente ohne Herstellersupport ist eine bekannte, dauerhafte Gefährdung: Neue Lücken werden nicht mehr geschlossen.
A.5.9 Inventar der Informationen und anderen damit verbundenen Werte ist die Voraussetzung für alles Weitere. Ohne Inventar mit Versionsständen wissen Sie nicht, welche Systeme betroffen sind. Wie die Controls aus Anhang A zusammenspielen, erklärt unser Überblick über alle 93 ISO-27001-Controls.
A.8.32 Änderungssteuerung greift beim Upgrade selbst. Ein Versionswechsel der Laufzeitumgebung ist eine Änderung an einem produktiven System und braucht Test, Freigabe und einen Rückfallplan.
Abschnitt 6.1.3 Informationssicherheitsrisikobehandlung regelt, was mit Systemen geschieht, die Sie nicht rechtzeitig umstellen. Die Norm verlangt einen Risikobehandlungsplan und die Zustimmung der Risikoeigentümer zu diesem Plan und zu den verbleibenden Restrisiken.
Upgrade-Plan oder befristete Risikoakzeptanz
Für jede PHP-8.2-Installation nach dem 31. Dezember gibt es damit nur zwei auditfeste Zustände. Entweder liegt ein Upgrade-Plan mit Terminen und Verantwortlichen vor. Oder es gibt eine dokumentierte Risikoakzeptanz, die befristet ist, kompensierende Maßnahmen benennt und vom Risikoeigentümer unterschrieben wurde. Eine unbefristete Akzeptanz ohne Enddatum ist keine Risikobehandlung, sondern eine Dauerausnahme. Auditoren lesen sie auch so.
Der Fall, der regelmäßig zu einer Abweichung führt, ist der dritte: Das System steht weder im Inventar noch im Risikoregister. Dann fehlt nicht nur die Maßnahme, sondern der Nachweis, dass der Prozess nach A.8.8 überhaupt funktioniert.
NIS2: § 30 BSIG
Für Unternehmen, die unter NIS2 fallen, ist der Umgang mit Schwachstellen in Deutschland eine gesetzliche Pflicht. § 30 Absatz 2 BSI-Gesetz nennt unter Nummer 5 die Sicherheit bei Erwerb, Entwicklung und Wartung von IT-Systemen einschließlich Management und Offenlegung von Schwachstellen. Nummer 9 verlangt die Verwaltung von IKT-Assets, also im Kern ein Inventar.
Nach § 38 BSIG muss die Geschäftsleitung diese Maßnahmen umsetzen und ihre Umsetzung überwachen. Bei einem bekannten Stichtag wie dem PHP 8.2 End of Life sollte sie deshalb wissen, wie viele Systeme betroffen sind und bis wann sie umgestellt werden.
Welche Pflichten NIS2 darüber hinaus mit sich bringt, fasst unser Leitfaden zu den NIS2-Anforderungen zusammen.
Ihre Optionen: Upgrade, verlängerter Support oder Isolation
Für jedes System auf PHP 8.2 oder älter bleiben drei Wege. Sie unterscheiden sich darin, ob sie das Problem lösen oder nur Zeit kaufen.
| Option | Was sie leistet | Nachteile | Geeignet für |
|---|---|---|---|
| Upgrade auf PHP 8.4 oder 8.5 | Beseitigt das Problem. Offizielle Sicherheitsupdates bis Ende 2028 bzw. Ende 2029 | Testaufwand, mögliche Inkompatibilitäten mit Frameworks, Plugins und Eigenentwicklungen | Alle Systeme, deren Anwendung sich in den nächsten Wochen testen lässt |
| Verlängerter Support über Linux-Distribution oder LTS-Anbieter | Sicherheitskorrekturen als Backport über das offizielle Ende hinaus | Abdeckung hängt vom Anbieter ab, gilt nur für dessen Pakete, Versionsnummer ändert sich nicht, Nachweis aufwendiger | Systeme mit festem Upgrade-Termin im Jahr 2027 |
| Isolation oder Abschaltung | Senkt die Angriffsfläche, etwa durch Zugriff nur über VPN | Die Schwachstellen bleiben, nur der Zugang wird enger. Kein Dauerzustand | Altanwendungen ohne Upgrade-Pfad, Verwaltungsoberflächen von Geräten |
Upgrade
Das Upgrade ist die einzige Option, die das Problem beseitigt, statt es zu verschieben. Der Aufwand hängt weniger von PHP selbst ab als von dem, was darauf läuft. Ein aktuelles WordPress oder Typo3 mit gepflegten Erweiterungen läuft meist ohne größere Anpassungen auf PHP 8.4. Eigenentwicklungen und Shops mit vielen Plugins brauchen dagegen echte Tests.
Verlängerter Support
Einige Linux-Distributionen pflegen ihre PHP-Pakete länger als das PHP-Projekt. Debian 12 liefert PHP 8.2 aus und erhält über Debian LTS bis 2028 Sicherheitsupdates. Daneben bieten kommerzielle Anbieter verlängerten Support für ältere PHP-Versionen an.
Der Haken: Der Schutz gilt nur für Pakete aus genau dieser Quelle. Wer PHP aus einem Drittanbieter-Repository bezieht, selbst kompiliert oder in einem eigenen Container-Image mitliefert, profitiert nicht davon. Für das Audit brauchen Sie außerdem einen Beleg, welcher Anbieter den Support leistet und bis wann.
Isolation
Isolation passt dort, wo kein Upgrade möglich ist, etwa bei einer Altanwendung ohne Hersteller oder bei Geräten mit PHP-basierter Verwaltungsoberfläche. Bei Firewalls, NAS-Systemen und Load Balancern kommt die Korrektur ohnehin als Firmware-Update des Herstellers. Bis dahin sollten solche Oberflächen nicht aus dem Internet erreichbar sein. Eine Web Application Firewall kann bekannte Angriffsmuster abfangen, ersetzt aber keinen Patch.
Ein realistischer Upgrade-Plan bis zum 31. Dezember
Ab Anfang November bleiben knapp acht Wochen und die zweite Dezemberhälfte fällt in vielen Unternehmen in einen Change Freeze. Realistisch ist deshalb ein Plan, der die Umstellungen bis Mitte Dezember abschließt.
- Inventar erstellen (bis 13. November, IT-Betrieb). Erfassen Sie jeden Server, jedes Container-Image und jedes Hosting-Paket mit PHP, jeweils mit Version und Bezugsquelle der Updates. Vergessen Sie nicht die Websites, die eine Agentur oder ein Hoster für Sie betreibt, das Intranet, alte Kampagnenseiten und Staging-Umgebungen. Dazu gehören auch Geräte mit PHP-basierter Verwaltungsoberfläche wie Firewalls, NAS-Systeme und Load Balancer.
- Bewerten und priorisieren (bis 20. November, ISB mit IT-Leitung). Ordnen Sie jedes System einer der drei Optionen zu. Aus dem Internet erreichbare Systeme und Systeme mit personenbezogenen Daten kommen zuerst.
- Testen (23. November bis 4. Dezember, Entwicklung oder Dienstleister). Prüfen Sie jede Anwendung in einer Staging-Umgebung auf PHP 8.4 oder 8.5. Aktualisieren Sie vorher Frameworks, Plugins und Themes, denn ältere Versionen sind oft der eigentliche Blocker.
- Umstellen (7. bis 18. Dezember, IT-Betrieb). Führen Sie jede Umstellung als Change nach A.8.32 durch, mit Freigabe, Zeitfenster und Rückfallplan.
- Rest absichern (bis 31. Dezember, Risikoeigentümer). Was nicht umgestellt ist, bekommt eine befristete Risikoakzeptanz mit Enddatum, kompensierenden Maßnahmen und Unterschrift.
Ein Beispiel: Ein Maschinenbauer mit 120 Beschäftigten findet bei der Inventur sieben PHP-Systeme. Intranet und Kundenportal laufen auf eigenen Servern mit PHP 8.2, zwei Marketing-Websites betreibt eine Agentur, dazu kommen ein B2B-Shop, ein NAS und eine Firewall mit PHP-basierter Verwaltungsoberfläche. Intranet und Portal sind am 10. Dezember auf PHP 8.4 umgestellt. Die Agentur bestätigt schriftlich das Upgrade der Websites. Der Shop braucht ein Plugin, das erst im Februar erscheint, also unterschreibt die IT-Leitung eine Risikoakzeptanz bis 31. März 2027, mit Zugriff nur über eine Web Application Firewall und wöchentlicher Prüfung. NAS und Firewall erhalten Firmware-Updates, ihre Oberflächen sind nur noch intern erreichbar.
Was Sie dokumentieren sollten
Halten Sie für jedes System fest: Version vor und nach der Umstellung, Datum, Change-Ticket mit Freigabe, Testergebnis und gegebenenfalls die Bestätigung des Hosters oder der Agentur. Für jede Ausnahme gehören Begründung, Enddatum, kompensierende Maßnahmen und Unterschrift des Risikoeigentümers dazu.
Was Auditoren sehen wollen
Ein Auditor erwartet nicht, dass es in Ihrem Unternehmen keine Altsysteme gibt. Er erwartet, dass Sie davon wissen und eine nachvollziehbare Entscheidung getroffen haben. Im ersten Audit nach dem 31. Dezember 2026 werden typischerweise diese Nachweise angefragt:
- ein Inventar mit PHP-Versionen und End-of-Life-Daten, inklusive gehosteter Websites und Geräte
- ein Eintrag im Risikoregister zu veralteter Software mit Bewertung und Risikoeigentümer
- der Upgrade-Plan mit Terminen und Verantwortlichen sowie die Change-Tickets der durchgeführten Umstellungen
- für jede Ausnahme eine befristete, unterschriebene Risikoakzeptanz mit kompensierenden Maßnahmen
- Belege für den Patch-Stand, also Paket-Changelogs oder Bestätigungen von Hostern und Dienstleistern
- ein Prozess, der End-of-Life-Termine künftig überwacht, statt sie jedes Jahr neu zu entdecken
Der letzte Punkt ist der wichtigste. PHP 8.3 folgt in 14 Monaten und für Betriebssysteme, Datenbanken und Frameworks gilt dasselbe Muster. Ein Auditor bewertet deshalb weniger die einzelne Umstellung als die Frage, ob Ihr Schwachstellenmanagement den nächsten Stichtag selbst erkennt.
Schwachstellen und Fristen als Audit-Nachweis mit Kertos und Aikido
Die meisten Nachweise aus der Liste entstehen in den Tools Ihrer IT- und Entwicklungsteams, nicht im ISMS. Kertos schließt diese Lücke über die Integration von Aikido und Kertos. Aikido Security prüft Code, Cloud-Umgebungen und laufende Anwendungen auf Schwachstellen. Kertos liest diese Befunde zusammen mit den Behebungsfristen, die Sie selbst festgelegt haben, und prüft täglich, ob eine Frist überschritten ist. Das Ergebnis hinterlegt Kertos als Nachweis für die ISO-27001-Anforderungen an Schwachstellenmanagement, sichere Entwicklung und Sicherheitstests.
Die Verbindung ist rein lesend und ändert nichts in Aikido. Sie aktualisiert sich einmal täglich im Hintergrund oder auf Knopfdruck. Für Ihr Audit heißt das: Statt Screenshots zu sammeln, liegt die Antwort auf die Frage, ob Schwachstellen fristgerecht behoben werden, bereits vor.
Inventar und Risikoregister führen Sie in derselben Plattform. Die zertifizierten Experten von Kertos unterstützen Sie dabei, Ihr Schwachstellenmanagement so aufzusetzen, dass der nächste End-of-Life-Termin kein Sonderprojekt mehr ist. Wenn Sie sehen möchten, wie das in Ihrer Umgebung aussieht, vereinbaren Sie eine Demo.
Häufig gestellte Fragen
Wann endet der Support für PHP 8.2?
Das PHP-Projekt liefert für PHP 8.2 bis zum 31. Dezember 2026 Sicherheitsupdates. Der aktive Support mit regulären Fehlerkorrekturen endete bereits am 31. Dezember 2024. Ab dem 1. Januar 2027 werden auch kritische Sicherheitslücken in PHP 8.2 nicht mehr geschlossen.
Was passiert, wenn ich PHP 8.2 nach dem End of Life weiter nutze?
Die Anwendung läuft weiter, aber neue Sicherheitslücken bleiben offen. Bei PHP2Shell im Oktober 2026 erhielten EOL-Versionen kein offizielles Release, sondern nur Quellcode-Backports oder gar keinen Fix. Unter ISO 27001 brauchen Sie für jedes solche System einen Upgrade-Plan oder eine befristete, dokumentierte Risikoakzeptanz.
Auf welche PHP-Version sollte ich upgraden?
Auf PHP 8.4 oder 8.5. PHP 8.4 erhält Sicherheitsupdates bis 31. Dezember 2028, PHP 8.5 bis 31. Dezember 2029. Ein Upgrade auf PHP 8.3 ist wenig sinnvoll, weil dessen Support bereits am 31. Dezember 2027 endet.
Ist veraltete Software ein Verstoß gegen ISO 27001?
Nicht automatisch. ISO 27001:2022 verlangt nach A.8.8 und Abschnitt 6.1.3, dass Sie das Risiko kennen, bewerten und behandeln. Ein EOL-System mit Upgrade-Plan oder befristeter Risikoakzeptanz ist auditfähig; ein System, das weder im Inventar noch im Risikoregister steht, führt dagegen regelmäßig zu einer Abweichung.
Woran erkenne ich, ob mein PHP trotz alter Versionsnummer gepatcht ist?
An der Versionsnummer allein nicht, weil Hoster und Linux-Distributionen Korrekturen oft als Backport ohne neue Nummer einspielen. Prüfen Sie das Changelog des PHP-Pakets Ihrer Distribution oder lassen Sie sich von Ihrem Hoster schriftlich bestätigen, welche CVEs behoben sind. Diese Bestätigung dient im Audit zugleich als Nachweis.
