Gestern wurden zwei kritische Sicherheitslücken in PHP mit dem Namen „php2shell“ öffentlich bekannt gemacht: CVE-2026-109618 und CVE-2026-109619. Beide ermöglichen es Angreifern, ohne Authentifizierung Code auf verwundbaren Servern auszuführen. Da es außer einem PHP-Update keine verlässliche Möglichkeit gab, das Risiko zu entschärfen, haben wir uns vorsorglich dazu entschieden, unsere eigenen und die von uns gehosteten Kundendienste vorübergehend offline zu nehmen.
Einen Tag später ist es Zeit, zurückzublicken und zu schauen, was wir aus den Ereignissen gelernt haben.
Die CosmoCode-Dienste sind wieder online
Alle PHP-basierten Dienste, einschließlich der von uns gehosteten Wikis, sind wieder online und laufen mit den gestern veröffentlichten PHP-Versionen.
Die offizielle PHP-Sicherheitsmitteilung mit den Details wurde um 14:00 UTC veröffentlicht. Gleichzeitig wurden neue PHP-Versionen bereitgestellt.
Kurz darauf folgten aktualisierte PHP-Pakete für Debian (unsere bevorzugte Linux-Distribution). Wir begannen damit, die ersten Dienste zu aktualisieren und neu zu starten.
Die offiziellen Docker-Pakete ließen noch einige Stunden auf sich warten, bis sie auf Docker Hub verfügbar waren. Etwa 20 Minuten später wurden bereits neue DokuWiki-Docker-Images veröffentlicht.
Gegen 19:30 UTC (21:30 Uhr deutscher Zeit) liefen alle unsere Systeme wieder normal.
Ich möchte meinen Kollegen Karsten und Tilo danken, die mit mir bis zu dieser späten Stunde gearbeitet haben. Mein Dank gilt auch den vielen Freiwilligen der beteiligten Open-Source Communities, die größtenteils unbezahlt an einer so schnellen Lösung mitgewirkt haben!
War das wirklich nötig?
Wie immer, wenn eine Katastrophe abgewendet wurde, stellt sich im Nachhinein die Frage, ob es überhaupt dazu gekommen wäre.
Als die ersten Informationen über die Sicherheitslücke bekannt wurden, gab es noch keine konkreten Details. Es war unklar, ob sich das Risiko irgendwie eindämmen ließ. Die einzige Information, die uns vorlag, war ein Mastodon-Beitrag von Gina Peter Banyard, einer Entwicklerin des PHP-Kernteams:
Das Einzige, was ich sagen kann, ist, dass es nur eine Möglichkeit gibt, das Problem zu entschärfen: PHP zu patchen bzw. zu aktualisieren. Leider weiß ich zu viel.
Gleichzeitig meldete Cloudflare, dass bereits Anfragen erkannt und blockiert worden waren, die wie Versuche aussahen, die Sicherheitslücke auszunutzen – oder zumindest das, was zu diesem Zeitpunkt darüber bekannt war. Es schien also, dass zumindest Teile der Schwachstelle bereits bekannt waren und aktiv ausgenutzt wurden.
Deshalb entschieden wir uns für die drastische Maßnahme, unsere Dienste offline zu nehmen. Mit dieser Einschätzung waren wir nicht allein: Im Laufe des Tages kamen zahlreiche andere Organisationen, von kleinen Unternehmen bis hin zu großen Einrichtungen zum selben Schluss.
Inzwischen sind die Details bekannt, und es sieht so aus, als sei die Sicherheitslücke tatsächlich etwas schwieriger auszunutzen als zunächst angenommen. Die befürchtete große Welle automatisierter Angriffe ist daher bislang ausgeblieben. Trotzdem sehen wir in den Logs unserer CrowdSec-Web Application Firewall bereits erste Versuche, unsere Systeme über die neuen Schwachstellen anzugreifen.
Wird so etwas wieder passieren?
Der Beitrag der PHP Foundation zu diesem Vorfall ist lesenswert. Die Bedrohung war offenbar schon länger in groben Zügen bekannt. Es war jedoch schwierig einzuschätzen, ob und wie sich die Schwachstelle überhaupt ausnutzen ließ – insbesondere angesichts der begrenzten Ressourcen, die einem Open-Source-Projekt zur Verfügung stehen.
KI verändert die Situation grundlegend. Software, die über das Internet erreichbar ist, steht inzwischen unter ständiger Beobachtung. KI-Labore investieren riesige Mengen an Rechenleistung und Tokens, um anschließend verkünden zu können, dass sie eine schwerwiegende Sicherheitslücke entdeckt und damit das Internet “sicherer” gemacht haben. Das ist gleichzeitig richtig und falsch.
KI gibt aber auch Angreifern neue Möglichkeiten, bekannte Schwachstellen auszunutzen – unabhängig von ihren eigenen Fähigkeiten. Sicherheitslücken bis zu ihrer koordinierten Veröffentlichung unter Verschluss zu halten, wie es auch gestern versucht wurde, wird zunehmend schwieriger. Selbst die gestrige Veröffentlichung wich bereits vom ursprünglichen Zeitplan ab, weil Informationen über die Schwachstelle während der vereinbarten Geheimhaltungsfrist durchgesickert waren. Oft reicht inzwischen schon das Gerücht über eine Sicherheitslücke, damit LLMs diese eigenständig reproduzieren und funktionierende Exploits erzeugen.
Wir müssen also damit rechnen, dass weitere schwerwiegende Sicherheitslücken entdeckt werden und die Vorwarnzeiten noch kürzer ausfallen. Drastische Maßnahmen wie die gestrigen könnten damit künftig häufiger notwendig werden.
Was unternimmt CosmoCode?
Wir müssen uns auf diese neue Realität einstellen und für den nächsten Vorfall besser vorbereitet sein. Glücklicherweise haben wir in den vergangenen Jahren unsere Infrastrukturverwaltung kontinuierlich verbessert und den Großteil unserer Dienste auf einen von uns selbst verwalteten Kubernetes-Cluster umgestellt. Diese neue Infrastruktur war gestern entscheidend dafür, dass wir so schnell reagieren und die notwendigen Updates bereitstellen konnten.
Trotzdem haben wir einige Erkenntnisse gewonnen:
Nicht alle Aktualisierungen innerhalb des Clusters liefen so reibungslos wie erhofft. Außerdem müssen wir möglicherweise verbessern, wie wir schnell alle Dienste identifizieren können, die eine bestimmte Technologie einsetzen. Das kann eine Programmiersprache sein, wie im gestrigen Fall, aber künftig auch eine bestimmte Bibliothek oder ein Framework. Darüber hinaus gibt es noch einige Altsysteme, die wir migrieren sollten.
Auch unsere Prozesse zur schnellen Benachrichtigung betroffener Kunden müssen wir verbessern. Bei unseren DokuWiki-Hosting-Kunden war es für mich am einfachsten, schnell einen Newsletter zu verschicken. Das hatte den zusätzlichen Vorteil, dass auch diejenigen informiert wurden, deren Wikis wir nicht hosten. Andere Kunden mussten wir hingegen einzeln kontaktieren.
Wenn Sie Unterstützung dabei benötigen, sich auf den nächsten Sicherheitsvorfall vorzubereiten, oder andere technische Herausforderungen haben, sprechen Sie uns gerne an. Wir besprechen mit Ihnen, wie wir Sie unterstützen können.