Sicherheit im Betrieb
PHP2Shell: wie wir an einem Tag gepatcht haben.
Am 21. Oktober 2026 um 16 Uhr hat das PHP-Team die Korrekturen für PHP2Shell veröffentlicht, die Sicherheitslücken CVE-2026-109618 und CVE-2026-109619. Um 21:45 Uhr lief die letzte Anwendung in unserem Hosting auf einer abgesicherten Version, die Testumgebungen folgten in der Nacht.
Dazwischen lagen ein offizielles Software-Paket, das zu spät kam, eines, das wir selbst erstellen mussten, und eine Anwendung, in der wir PHP im laufenden Betrieb getauscht haben. Hier steht, wie der Tag ablief und was ich daraus mitnehme.
Was hinter PHP2Shell steckt
PHP2Shell sind zwei Lücken in PHP selbst, geführt als CVE-2026-109618 und CVE-2026-109619 mit einem CVSS-Wert von 9,2. Im schlimmsten Fall führt ein Angreifer damit von außen eigenen Code auf dem Server aus. Betroffen ist also nicht ein CMS oder ein Plugin, sondern die Sprache darunter.
Die Korrekturen kamen als PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für PHP 8.1 und älter gibt es keinen Fix, weil diese Versionen keine Sicherheitsupdates mehr bekommen. Wer dort noch läuft, aktualisiert nicht einfach, sondern muss erst auf eine unterstützte Version umziehen.
Der Tag beginnt mit dem Bestand
Angekündigt wurde die Lücke am 20. Oktober, einen Tag vor dem Fix. Damit stand fest, an welchem Tag wir patchen, und wir haben unsere Leute für diesen Tag bis in den Abend eingeplant.
Am Vormittag haben wir jedes Hosting durchgesehen und je System drei Dinge festgehalten: die PHP-Version, wer das Image liefert und ob es für diese Version überhaupt einen Fix gibt. Daraus wurden vier Gruppen, und jede brauchte etwas anderes:
- Websites in unserem Hosting auf PHP 8.2 bis 8.5: Fix abwarten, Image neu erstellen, sichern und ausrollen.
- Anwendungen auf PHP 8.1: Hier kommt kein Fix. Wir haben den Code für eine neuere Version angepasst und die Kunden vorab um Freigabe gebeten, je System etwa ein halber Arbeitstag.
- Systeme, deren Image ein anderer Anbieter liefert oder die der Kunde selbst betreibt: Die Verantwortlichen haben am Mittag eine Mail mit Version, Fundstelle und Empfehlung bekommen.
- Eine Website, bei der wir das Risiko bis zum Fix nicht tragen wollten: Die haben wir am Mittag bewusst abgeschaltet.
16 Uhr: der Fix ist da, das Image nicht
Unsere Websites laufen in Docker-Containern, die auf den offiziellen PHP-Images aufsetzen. Wir spielen eine Korrektur also nicht von Hand auf jeden Server, sondern erstellen das Image neu und rollen es aus. Das ist sauber und wiederholbar, setzt aber voraus, dass das offizielle Image zuerst neu erscheint.
Genau das hat sich gezogen. Die Aktualisierung der offiziellen Images wurde um 17:16 Uhr freigegeben, der automatische Build bei Docker hat sie aber verpasst. Die Maintainer mussten ihn von Hand neu anstoßen, und das fertige Image für unsere Serverarchitektur lag erst gegen 18:35 Uhr vor.
Bei einer Lücke mit 9,2 fühlt sich dieses Warten ungefähr so lang an wie ein ganzer Arbeitstag. Immerhin war die eine Website, bei der wir nicht warten wollten, zu diesem Zeitpunkt schon seit Stunden offline.
Ab 18:35 Uhr: eine Website nach der anderen
Danach ging es der Reihe nach: Image neu erstellen, testen, Datenbanken sichern, zuerst die Testumgebung ausrollen und dann die Live-Website. Um 20:08 Uhr war die abgeschaltete Website wieder online, um 20:26 und 20:42 Uhr folgten die nächsten.
Nach jedem Update haben wir geprüft, ob die Seiten normal antworten, ob das Backend erreichbar ist und ob PHP Fehler meldet. Bei einer großen mehrsprachigen TYPO3-Website waren das rund 800 Seiten je Umgebung, dazu der Code der Erweiterungen.
Die erste Anwendung auf PHP 8.1 haben wir zuerst auf der Testumgebung umgestellt und erst nach dem Test live genommen, ohne Ausfall. Bei der zweiten liegt die PHP-Einstellung im Webhosting des Kunden. Wir haben den Code am Abend angepasst, der Kunde hat am nächsten Morgen umgestellt, und wir haben direkt danach jede Funktion durchgeklickt.
Wenn das offizielle Image nicht kommt
Für WordPress gibt es ein eigenes offizielles Image, und das war am Abend immer noch nicht neu erstellt. Warten hätte bedeutet, eine bekannte Lücke über Nacht offen zu lassen.
Also haben wir das Image selbst erstellt, auf Basis von php:8.3.36-fpm-alpine, mit denselben PHP-Erweiterungen, denselben Einstellungen und derselben WordPress-Version wie vorher. Seit 21:14 Uhr läuft die Website darauf, und sobald das offizielle Image nachzieht, stellen wir wieder um.
Ein selbst erstelltes Image ist für mich eine Brücke und kein Dauerzustand. Ich pflege lieber das offizielle Image mit als eine eigene Abzweigung, die in zwei Jahren niemand mehr erklären kann.
PHP tauschen im laufenden Container
Der heikelste Fall war eine Anwendung, deren Image ein anderer Anbieter erstellt und ausliefert. Wir hatten ihn am Mittag mit Version und Fundstelle angeschrieben und um ein neues Image gebeten, eine Antwort kam bis zum Abend nicht.
Gegen 21:45 Uhr haben wir PHP im laufenden Container selbst auf 8.4.27 angehoben. Vorher haben wir die alten Dateien gesichert, danach geprüft, dass der Webserver die neue Version lädt und die Schnittstellen dieselben Antworten liefern wie vorher. Die Anwendung war dafür nur wenige Sekunden nicht erreichbar.
Einen fremden Container fassen wir so normalerweise nicht an, und das soll auch die Ausnahme bleiben. Beim nächsten Ausliefern entsteht der Container wieder aus dem Image des Anbieters, und das spielen wir erst ein, wenn die korrigierte Version darin steckt.
Was in den Logs stand
Zwischen Bekanntwerden und Patch lagen Stunden, und in diesen Stunden suchen automatische Scanner das Netz nach offenen Stellen ab. Deshalb haben wir für jede Website die Zugriffe seit der Ankündigung ausgewertet.
Gefunden haben wir die erwarteten Wellen von POST-Anfragen, wie sie gerade weltweit gegen PHP-Seiten laufen. Auf einem Server hat CrowdSec rund 130 davon geblockt, bevor sie die Anwendung erreicht haben, der Rest wurde gedrosselt und lief ins Leere. Anzeichen für einen erfolgreichen Angriff haben wir auf keiner Website gefunden.
Was wir daraus mitnehmen
Ein Patch-Tag beginnt nicht um 16 Uhr, sondern mit dem Bestand. Wer am Vormittag weiß, welche Version wo läuft und wer welches Image liefert, verliert am Abend keine Zeit mit Suchen.
PHP 8.1 bekommt seit Ende 2025 keine Sicherheitsupdates mehr, und genau dort tut so ein Tag weh. Wenn deine Anwendung noch darauf läuft, plane den Umstieg, bevor die nächste Lücke ihn für dich plant.
Auf die Community ist Verlass, aber nicht auf die Minute. Wer auf offiziellen Images aufsetzt, braucht einen Plan für den Abend, an dem eines davon nicht rechtzeitig kommt.
Unsere Zusage für kritische Updates lautet innerhalb von 24 Stunden. Diesmal war die letzte Live-Anwendung am selben Abend abgesichert, auf das Warten auf Docker hätte ich trotzdem gern verzichtet.
Häufige Fragen
Was zu PHP2Shell gefragt wird
Welche Websites sind von PHP2Shell betroffen?
Jede Website und Anwendung auf PHP, die noch nicht auf 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder höher steht. Das gilt für TYPO3, WordPress und jede eigene PHP-Anwendung gleichermaßen.
Gibt es einen Fix für PHP 8.1?
Nein. PHP 8.1 bekommt seit Ende 2025 keine Sicherheitsupdates mehr, die Lücke schließt nur der Umstieg auf PHP 8.2 oder neuer.
Müssen Kunden in eurem Hosting etwas tun?
Nein. Alle Websites in unserem Hosting laufen seit dem Abend des 21. Oktober auf einer abgesicherten Version, und wer betroffen war, hat von uns eine Mail bekommen.
Reicht es, nur die PHP-Version im Hosting-Panel umzustellen?
Nicht immer. Ist die Anwendung für eine ältere Version geschrieben, muss erst der Code angepasst werden, sonst schließt man die Lücke und öffnet dafür eine Fehlerseite.
Signal senden
Fragen zu PHP2Shell oder deinem Hosting? Sprich direkt mit Tim.
Hosting Sicherheitsupdates PHP
Tim Rücker
Nächster Schritt
Deine Anwendung läuft noch auf PHP 8.1?
Wie wir Websites betreiben und Sicherheitsupdates einspielen, steht bei unserem Hosting. Wenn eine bestehende TYPO3-Website jemanden braucht, der sie auf eine unterstützte Version bringt, findest du das bei der TYPO3-Wartung.