Kritische PHP-Lücke – geschlossen am Abend der Veröffentlichung
Am 21. Oktober 2026 wurden zwei Sicherheitslücken in PHP öffentlich, die unter dem Namen „PHP2Shell“ bekannt wurden (CVE-2026-109618 und CVE-2026-109619). Bewertung: 9,2 von 10. Die Lücken erlauben es, ohne jede Anmeldung Code auf dem Server auszuführen, und sie wurden bereits aktiv ausgenutzt. Betroffen ist praktisch jede PHP-Website, und damit jede TYPO3-Installation.
Dieser Beitrag erzählt, wie wir 14 Installationen bei 11 Kunden durch diesen Tag gebracht haben: erst abgeschirmt, dann gepatcht, alles am selben Abend.
Die Herausforderung
Die Korrektur war für 16:00 Uhr angekündigt. Bis dahin ließ sich nichts patchen, und auch danach nicht sofort:
- Der Patch ist nicht das Image. Unsere Kundenprojekte laufen in Docker-Containern auf Basis der offiziellen PHP-Images. Die werden erst Stunden nach der Veröffentlichung gebaut. Bis dahin ist ein „Rebuild“ ein Neubau mit der alten, verwundbaren Version.
- Alte PHP-Versionen bekommen gar keinen Patch. Die Korrektur gab es nur für PHP 8.2 bis 8.5. Was auf 8.1 oder älter läuft, bleibt verwundbar, bis es umgestellt ist.
- Abschalten war keine Option. Kontaktformulare, Terminbuchungen, Newsletter-Anmeldungen, Online-Bewerbungen: Hinter den Websites hängt Geschäft.
- Viele Projekte, ein Abend. Jede Installation hat ihre eigene Pipeline, ihre eigene Prüfung und ihren eigenen Deploy. Das händisch nacheinander abzuarbeiten, hätte bis tief in die Nacht gedauert.
Unsere Lösung
1. Vorbereiten, bevor es den Patch gibt
Noch am Vormittag haben wir für jedes betroffene Projekt die Tickets angelegt, geschätzt und als Sicherheitswartung beauftragt, aber geparkt. Ein kleiner Wächter prüfte alle fünf Minuten, ob die korrigierte Version tatsächlich verfügbar ist. Erst dann gab er die Tickets an unsere Entwicklungs-Pipeline frei: bauen, auf Staging prüfen, Code-Review, ausrollen.
2. Abschirmen, solange es keinen Patch gibt
Ab 16:15 Uhr, eine Viertelstunde nach der Veröffentlichung, haben wir alle Installationen abgeschirmt. Die Lücke wird über Anfragen im Upload-Format ausgenutzt, die PHP schon verarbeitet, bevor TYPO3 überhaupt startet. Der Webserver weist genau diese Anfragen nun ab, bevor sie PHP erreichen. Die Websites blieben normal erreichbar.
Das hatte einen Preis: Uploads, manche Formulare und das Speichern im Redaktionssystem gingen vorübergehend nicht. Wo das schmerzte, haben wir gezielt nachgesteuert: Redakteure mit laufender Sitzung bekamen eine Freischaltung für ihren Anschluss, und die Terminformulare einer Arztpraxis haben wir so umgestellt, dass sie trotz der Sperre wieder funktionierten. Zwischen 16:31 und 16:34 Uhr haben wir alle betroffenen Kunden informiert, was gesperrt ist und warum.
Eine Lücke, die sich nicht sofort patchen lässt, lässt sich oft sofort abschirmen.
3. Prüfen statt vertrauen
Gegen 17:40 Uhr tauchten auf Docker Hub die neuen Versionsnummern auf, aber die Einträge waren noch leer, die Images dahinter fehlten. Unser Wächter hielt das für die Freigabe. Die Entwicklungs-Pipeline bemerkte beim Bauen, dass im Container weiterhin die alte PHP-Version steckte, und schlug Alarm. Wir haben daraufhin alles angehalten und einen bereits angelaufenen Produktions-Deploy abgebrochen, bevor er die Abschirmung entfernen konnte. Zu keinem Zeitpunkt lief eine Website ungeschützt mit der alten Version. Seitdem prüft der Wächter nicht mehr, ob es ein Image gibt, sondern welche PHP-Version tatsächlich darin steckt.
4. Ausfälle unterwegs abfangen
Die echten Images kamen gegen 18:45 Uhr. Dann fiel der Paketserver aus, von dem PHP-Erweiterungen wie Imagick geladen werden: Die halbe Welt baute gleichzeitig neu. Mehrere Deploys brachen ab. Weil ein Deploy erst nach erfolgreichem Build umschaltet, blieb die laufende Website jeweils unverändert und abgeschirmt. Wir haben die Builds so erweitert, dass sie die Erweiterungen bei einem Ausfall direkt aus dem Quellcode bauen, und sie erneut ausgerollt.
Das Ergebnis
- 14 Installationen bei 11 Kunden liefen am selben Abend auf der korrigierten PHP-Version.
- Die erste um 18:58 Uhr, die letzte um 21:02 Uhr – gut zwei Stunden, nachdem die echten Images verfügbar waren.
- Keine Website wurde abgeschaltet. Die Abschirmung fiel mit dem Patch wieder weg.
- Jeder Kunde wurde zweimal informiert: bei der Abschirmung und nach dem Update.
Wo kein Patch existiert, bei Systemen auf PHP 8.1 und älter, bleibt die Abschirmung bestehen, bis die Umstellung auf eine unterstützte Version erfolgt ist. Die betroffenen Kunden haben wir gesondert informiert.
Fazit
Bei einer kritischen Lücke entscheidet sich nicht in der Nacht, wie schnell sie geschlossen ist, sondern vorher: ob es eine Pipeline gibt, die ohne Handarbeit baut, prüft und ausrollt, ob die Server einheitlich aufgesetzt sind, und ob jemand den Schutz schon vor dem Patch setzen kann.
Der ehrliche Nachsatz: Nicht alles lief glatt. Leere Images, ein voreiliger Wächter und ein ausgefallener Paketserver haben den Abend verlängert. Entscheidend war, dass keiner dieser Fehler eine Website ungeschützt gelassen hat.
