Am 21. Oktober 2026 wurden zwei kritische Sicherheitslücken in PHP bekannt. CVE-2026-109618 und CVE-2026-109619, besser bekannt als „PHP2Shell“, erreichen einen CVSS-Score von 9,2. Der Patch war für 16 Uhr angekündigt. Ein öffentlicher Proof of Concept tauchte allerdings schon deutlich früher auf. Zwischen „Exploit verfügbar“ und „Patch verfügbar“ lag also ein ganzer Arbeitstag und diese Lücke mussten wir überbrücken.
In diesem Beitrag beschreiben wir, wie wir den Tag strukturiert haben, welche Entscheidungen wir bei unterschiedlichen Kundensystemen getroffen haben und Learnings, die wir aus der Situation gewonnen haben.
Warum diese Lücke so gefährlich war
PHP ist die Grundlage für einen großen Teil des Webs, von WordPress über Shopsysteme bis hin zu Nextcloud. Betroffen waren praktisch alle PHP-Versionen der letzten 20 Jahre. Die Lücke erlaubte es Angreifern, ohne Anmeldung eigenen Code auf dem Server auszuführen. Weil der Angriff im PHP-Kern greift, also noch bevor die eigentliche Anwendung startet, halfen Anwendungsupdates oder Security-Plugins nichts. Nur das PHP-Update selbst schloss die Lücke. Alles andere konnte das Risiko höchstens senken.
Warum wir nicht improvisieren mussten
Der wichtigste Teil unserer Reaktion passierte lange vor dem 21. Oktober. Vor einiger Zeit haben wir einen festen Prozess für sicherheitsrelevante Meldungen eingeführt. Er ist bewusst einfach gehalten, damit er im Alltag tatsächlich gelebt wird.
Herzstück ist ein eigener Security-Channel in unserem Matrix-Chat. Sicherheitsmeldungen erreichen uns über viele Wege. Wir verfolgen einschlägige Security-Mailinglisten wie oss-security, lesen die gängigen IT-Fachmagazine und bekommen CVE-Meldungen aus zahlreichen weiteren Quellen. Damit aus dieser Informationsflut eine geordnete Reaktion wird, gilt eine einfache Regel. Wer im Team eine Meldung entdeckt, die uns oder unsere Kunden betreffen könnte, legt dafür ein Ticket in unserem internen Security-Tracker an und postet den Link in den Channel.
Danach gilt eine verbindliche Rückmeldepflicht. Jede Person im Team meldet zurück, ob ihre Systeme betroffen sind. Wer nicht betroffen ist, bestätigt das kurz. Wer betroffen ist, dokumentiert im Ticket, welche Systeme betroffen sind und welche Maßnahmen geplant sind.
Das klingt unspektakulär, löst aber gleich drei Probleme. Erstens geht keine Meldung im allgemeinen Chatrauschen unter. Zweitens ist auf einen Blick sichtbar, wer sich bereits zurückgemeldet hat und wo noch eine Antwort fehlt. Drittens bleibt im Nachhinein nachvollziehbar, wann eine Meldung aufkam und wer betroffen war.
Am 21. Oktober mussten wir deshalb keine Strukturen erfinden. Die Meldung zu PHP2Shell lief durch denselben Kanal wie jede andere Sicherheitsmeldung. Innerhalb kurzer Zeit war klar, wer welche Systeme betreut und wo gehandelt werden muss. Die Zeit, die wir uns damit gespart haben, konnten wir in das stecken, was an diesem Tag wirklich zählte, nämlich Entscheidungen zu treffen und mit unseren Kunden zu sprechen.
Der Tag im Zeitverlauf
Vor 10 Uhr: Als Sofortmaßnahme haben wir die vom PHP-Team empfohlenen Mitigations auf allen von uns betreuten Systemen ausgerollt. Dazu gehörte unter anderem, Datei-Uploads und den Session-Upload-Progress zu deaktivieren. Im Laufe des Tages zeigte sich jedoch, dass diese Maßnahmen allein keinen verlässlichen Schutz boten. Deshalb haben wir parallel weitergehende Schritte vorbereitet.
11 bis 14 Uhr: Überall dort, wo eine Abschaltung spürbare Folgen für den laufenden Betrieb gehabt hätte, haben wir die Kunden persönlich angerufen und Freigaben eingeholt, um Systeme vorübergehend vom Netz zu nehmen. Eine Abschaltung kostet potenziell Umsatz und Erreichbarkeit. Diese Entscheidung wollten wir nicht über die Köpfe unserer Kunden hinweg treffen.
Ab 16 Uhr: Mit der Veröffentlichung der Patches haben wir die Updates auf allen betroffenen Systemen eingespielt und die Systeme schrittweise wieder online genommen.
20 Uhr: Am Abend haben unsere betroffenen Kunden eine zusammenfassende Mail bekommen. Darin standen das Risiko, die ergriffenen Maßnahmen und ein Ausblick. Wir haben auch ausdrücklich darauf hingewiesen, dass PHP-Anwendungen bei anderen Hostern oder im Eigenbetrieb separat geprüft werden müssen.
Vier Fälle, vier Lösungen
Nicht jedes System lässt sich einfach abschalten oder patchen. Vier Beispiele aus unserem Kundenstamm zeigen, wie unterschiedlich die Lösungen aussehen mussten.
Altlasten abschalten: Ein Kunde betrieb noch mehrere Webseiten auf PHP 7.4, das schon lange keinen offiziellen Support mehr hat. Die weniger kritischen Seiten haben wir nach Rücksprache kurzerhand abgeschaltet.
Migrieren, wo Abschalten keine Option ist: Ein Online-Shop und eine Bestellsoftware, über die laufend Bestellungen eingingen, liefen ebenfalls noch auf PHP 7.4 und konnten nicht vom Netz. Beide haben wir noch am selben Tag auf PHP 8 migriert. Interne Anwendungen, die nicht öffentlich erreichbar sein müssen, haben wir hinter das VPN verlegt.
Statische Ersatzseite statt CMS: Bei einer TYPO3-Website reichten die Mitigations nicht aus. In Absprache mit dem Kunden haben wir die Seite komplett offline genommen und stattdessen eine schnell erstellte statische Ersatzseite ausgeliefert, die den Ausfall erklärt und das Impressum weiterhin verfügbar hielt.
Einmal ändern, überall aktiv mit NixOS: Bei unserem Hosting setzen wir auf NixOS. Dort pflegen wir die Konfiguration aller Server zentral an einer Stelle. Zunächst haben wir dort die Schutzmaßnahmen für Dienste wie beispielsweise Nextcloud, LimeSurvey, Roundcube und Matomo hinterlegt und die von außen erreichbaren PHP-Dienste abgeschaltet. Als das PHP-Update bereitstand, haben wir es einmal eingespielt und es war auf allen betroffenen Systemen aktiv. Jede Änderung ist dabei dokumentiert und lässt sich leicht zurücknehmen.
Was wir mitnehmen
Vorbereitung zahlt sich aus. Weil Abläufe und Zuständigkeiten schon vorher feststanden, konnten wir uns am Tag selbst auf Entscheidungen konzentrieren statt auf Organisation. Genau dafür lohnt sich die Arbeit, die man in ruhigen Zeiten investiert.
Kommunikation ist so wichtig wie Technik. Intern hat das an diesem Tag sehr gut funktioniert. Wir haben uns laufend abgestimmt, Zwischenstände geteilt und Entscheidungen schnell gemeinsam getroffen. Nach außen gilt dasselbe. Kunden wollen wissen, was los ist, auch wenn noch nicht alles klar ist. Beim nächsten Mal melden wir uns deshalb früher mit einer ersten kurzen Information und halten dafür vorbereitete Verteiler bereit, damit die Nachricht schnell bei allen ankommt.
Fazit
Der 21. Oktober hat gezeigt, dass im Ernstfall nicht die perfekte technische Lösung entscheidet. Entscheidend ist, schnell klare Entscheidungen treffen zu können. Was wird abgeschaltet, was wird migriert, was wird abgeschirmt und wer muss zustimmen? Wer diese Fragen vorher durchdacht hat, verliert im Ernstfall keine Zeit.
Allen, die PHP-Anwendungen betreiben, empfehlen wir, auch bei Systemen außerhalb der eigenen Verantwortung zu prüfen, ob die Updates eingespielt sind. Planen Sie außerdem den Ausstieg aus PHP 7.x, bevor die nächste Lücke ihn erzwingt.