Was für eine Woche … selbst Freunde und Familie, die nichts mit IT zu tun haben, fragten uns, wie wir sie überstanden haben. Was war passiert?
Am letzten Mittwoch hatte das PHP-Projekt Sicherheitsupdates für zwei kritische Lücken veröffentlicht, die unter dem Namen "php2shell" durch die Nachrichten gingen. An diesem Tag haben Behörden, Kliniken und auch einige Hoster ihre Websites vorsorglich vom Netz genommen. Dass wir unsere Projekte online ließen, bedarf einer Erklärung. Und wir möchten auch gern erzählen, was wir aus diesen intensiven Tagen gelernt haben.
Worum geht es bei php2shell?
Die beiden Lücken (CVE-2026-109618 und CVE-2026-109619) stecken tief im Kern von PHP, in der Speicherverwaltung und der Fehlerbehandlung. Unter bestimmten Bedingungen erlauben sie es einem Angreifer, ohne Anmeldung Code auf dem Server auszuführen. Betroffen waren praktisch alle PHP-Versionen der letzten Jahre, unabhängig davon, welches CMS oder Framework darauf läuft. Beide Lücken wurden mit einem CVSS-Wert von 9.2 als kritisch eingestuft.
Auch wenn dieses Release sehr lange geplant und vor allem geheim gehalten war, wurde es zum Schluss noch etwas hektisch. Die PHP Foundation hat das in ihrem Beitrag zum Release offen beschrieben. Geplant war die Veröffentlichung für den 22. Oktober. Schon am Nachmittag des 20. Oktober tauchten die CVE-Nummern aber im Netz auf, kurz darauf ein Video mit einem funktionierenden Proof of Concept. Am Morgen des 21. Oktober veröffentlichte ein Anbieter von Container-Images den Fix, mehr als sechs Stunden vor dem koordinierten Termin. Das PHP-Team zog das Release deshalb auf den 21. Oktober um 16:00 Uhr (MESZ) vor.
Wie der 21. Oktober bei uns ablief
Für Flownative Beach bauen wir unsere PHP-Images selbst, direkt aus dem Quellcode. Das kostet uns im Alltag etwas mehr Arbeit, hat sich an diesem Tag aber ausgezahlt: Wir mussten nicht warten, bis Linux-Distributionen fertige Pakete bereitstellen. Debian zum Beispiel hatte die gepatchten Pakete erst nach 21 Uhr.
Unser Tag im Überblick:
- Mittags bis nachmittags: Wir haben die Lage bewertet und uns vorbereitet. Unsere eigenen Systeme außerhalb von Beach, auf denen PHP läuft, haben wir vorsorglich per Firewall abgeschottet.
- 16:00 Uhr: Das PHP-Team veröffentlicht die gepatchten Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Wenige Minuten später starten unsere Builds.
- Ab 19:00 Uhr: Die neuen Images sind fertig, und wir deployen alle Beach-Instanzen neu. Nach rund sechs Minuten läuft der allergrößte Teil der Projekte auf gepatchtem PHP.
- Abends: Wir prüfen alle Cluster Container für Container und ziehen eine Handvoll Nachzügler einzeln nach. Danach haben wir alle aktiven Beach-Kunden per E-Mail informiert.
Warum wir nicht alles abgeschaltet haben
Die Frage haben uns in den Tagen danach einige von euch gestellt, und sie ist berechtigt. Das BSI und die amerikanische CISA hatten empfohlen, Websites vom Netz zu nehmen, und einige Hoster haben genau das getan, teils für mehrere Stunden. Bei klassischem Shared Hosting ist das eine nachvollziehbare Entscheidung: Dort laufen oft sehr viele Websites auf demselben Server, mit gemeinsamen Dateisystemen und einer bunten Mischung von PHP-Applikationen. Eine einzige ausgenutzte Lücke kann dort weit reichen.
Beach ist anders aufgebaut, und deshalb sind wir zu einer anderen Abwägung gekommen.
Patchen ging schneller als Ab- und wieder Einschalten
Die Empfehlung, Websites abzuschalten, galt ausdrücklich für den Fall, dass keine Updates verfügbar sind. Bei uns lagen zwischen der Veröffentlichung der Patches und dem Rollout auf fast alle Instanzen rund drei Stunden (und ja, uns kam die Zeit wirklich auch unendlich lange vor). Die meisten Hoster und Unternehmen haben wenn, dann erst mit der Veröffentlichung der Patches um 16 Uhr ihre Systeme vom Netz genommen. Wir hätten also kaum Zeit gewonnen, es ging um ein sehr kleines Zeitfenster.
Jede Beach-Instanz läuft isoliert
Bei Beach läuft jede Instanz in einem eigenen Container, und jedes Projekt hat einen eigenen, abgeschotteten Bereich im Cluster. Netzwerkregeln sorgen dafür, dass eine Instanz nur vom vorgeschalteten Webserver und von unseren Systemen für Betrieb und Monitoring erreicht werden kann, nicht von anderen Projekten. PHP läuft dort ohne Administratorrechte und ohne Möglichkeit, sich solche Rechte zu verschaffen. Die Container haben keinen Zugriff auf die Steuerung des Clusters.
Selbst wenn ein Angreifer Code in einer Instanz hätte ausführen können, wäre er in diesem einen Container geblieben.
Jedes Deployment sorgt für einen sauberen Zustand
Das Dateisystem einer Beach-Instanz ist flüchtig. Der Anwendungscode kommt bei jedem Start frisch aus dem gebauten Image, alles andere verschwindet beim nächsten Neustart. Eine typische Folge solcher Sicherheitslücken ist eine eingeschleuste Datei, z.B. eine Web-Shell, über die ein Angreifer später wiederkommt. Bei Beach überlebt so etwas keinen Container-Neustart.
Mit dem Rollout am Abend des 21. Oktober haben wir jeden einzelnen Container ersetzt. Selbst wenn vorher etwas eingeschleust worden wäre, wäre es damit verschwunden.
Abschalten ist in jedem Fall ein Schaden
Für einen Onlineshop, ein Mitgliederportal oder eine Unternehmenswebsite bedeutet ein Ausfall von mehreren Stunden echten Schaden. Wir haben deshalb abgewogen: ein Risiko für eine kurze Zeit in isolierten, flüchtigen Containern auf der einen Seite, ein sicherer Ausfall für alle auf der anderen. Uns fiel die Entscheidung auch nicht leicht, wir haben uns aber dafür entschieden, online zu bleiben.
Wir finden aber auch: Die Entscheidung, eine Website abzuschalten, liegt bei dem jeweiligen Betreiber. Einige von euch hatten einen besonderen Schutzbedarf und haben ihre Website selbst durch eine statische Seite ersetzt oder hinter einen Passwortschutz gelegt. Dabei haben wir gerne geholfen. Mit Beach geht das innerhalb weniger Minuten.
Wo die Abwägung anders ausfiel, haben wir übrigens sehr wohl abgeschaltet: Interne Systeme, die nicht wie Beach aufgebaut sind, haben wir sofort abgeschottet und erst nach dem Update wieder freigegeben.
Wir haben das genau beobachtet
Um eine solche Lücke auszunutzen, braucht ein Angreifer in der Regel Tausende Anfragen an dasselbe Ziel. Wir haben die Metriken aller Beach-Cluster für den 21. Oktober ausgewertet und mit dem Vortag verglichen: Anfragen pro Website, Fehlerraten, Abstürze und Speicherprobleme von PHP-Prozessen. Wir haben keine Hinweise auf eine erfolgreiche Ausnutzung gefunden.
Auch wenn uns da etwas durch die Lappen gegangen sein sollte: Durch die Isolation und den kompletten Austausch aller Container am Abend sehen wir auch keinen Weg, auf dem ein Angreifer sich dauerhaft hätte festsetzen können.
Was wir daraus lernen
Es gibt immer etwas zu lernen und zu verbessern, das ist ja auch gerade unser Anspruch. Selbst wenn der Tag am Ende für uns gut ausgegangen ist, gibt es eine Punkte die wir im Nachgang angehen werden:
- Schnellere Builds: Der Bau unserer PHP-Images hat rund zweieinhalb Stunden gedauert. Das war der größte Zeitverlust. Wir bauen die Images künftig auf unserer eigenen Infrastruktur und trennen PHP von den Erweiterungen, sodass bei einem Security Update nur noch PHP selbst neu gebaut werden muss.
- Schutz bevor es Patches gibt: Solange es noch keinen Patch gibt, wollen wir Schutzmaßnahmen wie angepasste PHP-Einstellungen oder Filterregeln zentral für alle Instanzen gleichzeitig setzen können.
- Früher informieren: Viele von euch haben am 21. Oktober einzeln nachgefragt, ob wir Bescheid wissen. Beim nächsten Mal melden wir uns proaktiv, sobald eine kritische Lücke bekannt ist, und halten euch auf dem Laufenden. Wir waren da vielleicht etwas zu sehr mit uns selbst beschäftigt …
Was ihr tun solltet
Auf Beach müsst ihr nichts tun. Eure Instanzen laufen seit dem Abend des 21. Oktober auf den gepatchten Versionen.
Wenn ihr PHP auch außerhalb von Beach einsetzt, zum Beispiel lokal, in eigenen CI-Pipelines, auf anderen Servern oder in Docker-Images, prüft bitte, ob dort eine aktuelle Version läuft. Unsere öffentlichen Images auf Docker Hub haben wir ebenfalls aktualisiert.
Und wenn ihr noch eine ältere PHP-Version nutzt oder nicht sicher seid, wie ihr euer Projekt auf eine aktuelle Version bringt: Meldet euch bei uns, wir helfen gerne.
PHP ist immer noch unser Lieblings-Ökosystem
Wir finden, dass viele Medien relativ gut und zutreffend über diese Sicherheitslücke berichtet haben. Manchmal natürlich auch etwas drollig formuliert. Und hin und wieder konnte man den Eindruck gewinnen, dass "PHP ein Problem ist" oder es ja schon immer klar wäre, dass PHP nicht so sicher ist. Das ist natürlich nicht so – man kann in PHP wunderbar saubere und sichere Applikationen entwickeln und betreiben (aber natürlich auch ganz dreckige und unsichere).
Was man aber sieht ist: PHP bildet das Rückgrat des modernen Internets, wahnsinnig viele Firmen und Organisationen hängen davon ab, dass PHP weiter entwickelt und gepflegt wird. Und trotzdem ist es ein kleines Team, hauptsächlich getragen von kleinen Unternehmen oder Freelancern, die alles am Laufen halten.
Deshalb möchten wir uns bedanken: Bei Volker Dusch, Nils Adermann, bei Tideways, beim gesamten PHP-Team und der PHP Foundation. Hinter einem solchen Release steckt monatelange, oft unsichtbare Arbeit, eine Koordination mit Forschenden, Distributionen und Hostern weltweit und am Ende ein vorgezogenes Release unter enormem Druck.
