Mittwochmorgen, noch vor dem Frühstück sehe ich auf meinem Handy eine Nachricht in einem privaten Gruppenchat: „Unsere Nextcloud ist offline, wegen einer Sicherheitslücke in PHP.“ Wenige Stunden später nehmen wir bei civiservice.de zum ersten Mal in unserer Geschichte alle Websites und CiviCRMs unserer Kund*innen vom Netz. Eine Entscheidung unter Zeitdruck, die wir nicht leichtfertig getroffen haben, aber jederzeit wieder so fällen würden.
Heute, zwei Tage später, lasse ich die ganze Affäre Revue passieren und erkläre, warum uns solche Tage im „KI-Zeitalter“ noch häufiger bevorstehen werden.
Goldrausch im Netz
Ich starte mit einer Analogie, die sich durch den gesamten Artikel ziehen wird: Als in Kalifornien 1848 Gold gefunden wurde, machten sich binnen kürzester Zeit Zehntausende auf den Weg, um ihr Glück zu versuchen. Dafür genügte eine Nachricht.
Im Netz läuft es mitunter ähnlich. Websites und Datenbanken verwahren unser modernes Gold: Daten wie Adressen, Zugangsdaten und Bankverbindungen. Rund um den Globus sitzen Menschen, die nur auf den nächsten Hinweis warten, wo sich ein schlecht bewachter Zugang zu diesem Gold auftut.
Am Dienstag dieser Woche kam so ein Hinweis, und ein besonders großer noch dazu: Es soll eine gravierende Sicherheitslücke in PHP geben. Mit dieser Programmiersprache laufen (je nach Zählung) rund 70 % aller Websites, darunter WordPress, Drupal und CiviCRM. Ein Ansturm auf Websites und Webanwendungen rund um den Globus war zu befürchten. Drei Besonderheiten haben diesen Vorfall aber zu einem wirklich außergewöhnlichen Ereignis gemacht.
Besonderheit 1: Die Lücke lag im Fundament
Sicherheitslücken stecken meist eher in einer einzelnen Anwendung. So etwa beim „wp2shell“-Vorfall im Sommer, der WordPress betraf. Mit der Analogie gesprochen: Ein einzelnes, großes Goldlager hatte eine schlecht gesicherte Tür. Doch dieses Mal steckte die Lücke in der Programmiersprache PHP selbst, also im Fundament, auf dem fast alle Lager stehen. Da hilft es nicht, wenn eine Anwendung noch so sauber programmiert und gründlich getestet ist. Die beiden PHP-Schwachstellen dieser Woche – getauft auf den Namen „PHP2Shell“ – greifen, bevor eine Anwendung wie WordPress überhaupt zum Zug kommt.
Konkret war eine Grundfunktion betroffen, die in weit verbreiteten Server-Konfigurationen mit PHP standardmäßig aktiv ist. Über die Sicherheitslücke dort könnten Hacker Schadcode direkt auf einen Server schleusen und Daten auslesen oder die Kontrolle über den Server übernehmen. Bei uns hieß das: Alle unsere über 200 WordPress-, Drupal- und CiviCRM-Installationen waren potenziell verwundbar.
Besonderheit 2: Ein Geheimnis, das keins blieb
Die Geschichte begann schon 2024. Bei einem externen Sicherheits-Check von PHP stieß ein Entwickler auf erste Anzeichen des Problems. Ein Angriff war theoretisch denkbar, aber niemand fand einen konkreten Weg, wie die Schwachstelle auch praktisch auszunutzen wäre. Andere Baustellen waren dringender und so blieb die Lücke erst einmal unbearbeitet liegen (PHP Foundation).
Im August und September 2026 fanden dann Forschende von drei Firmen die Schwachstellen unabhängig voneinander, alle mit Hilfe von KI, und meldeten sie vertraulich an das PHP-Team. Das ist der übliche Weg: Ein kleiner Kreis Eingeweihter erfährt von der Lücke, das PHP-Team baut eine Reparatur. Wichtige Anbieter in der „PHP-Lieferkette“ bekommen das Update dann schon vorab, um es am Stichtag sofort ausliefern zu können. Bis dahin gilt strenge Verschwiegenheit. Warum aber so geheim? Weil das Sicherheitsupdate selbst eine Schatzkarte ist: Wer sieht, was repariert wurde, weiß, wo der Zugang liegt und kann versuchen, ihn zu knacken.
Diesmal hielt die Verschwiegenheit nicht. Am Dienstagnachmittag kursierten die Kennnummern der Schwachstellen im Netz, samt Gerüchten über ihre Beschaffenheit. Das PHP-Team zog die Veröffentlichung daraufhin von Donnerstag auf Mittwoch, 16 Uhr vor. Am selben Abend stellten beteiligte Forschende dann versehentlich ein Video online, das den Angriff in Aktion zeigte. Es verriet nicht viel über die Details des Angriffs, aber die Goldgräber wussten jetzt zumindest, wo sie grob suchen mussten. Früher hätte es Wochen gedauert, aus solchen Informationsfragmenten einen funktionierenden Angriff zu bauen. Doch wo Goldsucher früher mit Waschpfanne im Fluss standen, rücken sie heute mit dem Bagger an: KI-Werkzeuge machen aus groben Hinweisen in Tagen oder Stunden funktionierende Angriffe, wofür Menschen ohne KI früher Wochen oder Monate brauchten.
Guten Morgen, das Internet brennt
Mein Frühstück musste an diesem Mittwochmorgen also warten, zuerst ging es schnellstmöglich ins Teammeeting mit meinen Kolleg*innen. Wir wussten, dass irgendwann der Tag kommen würde, an dem wir alle Systeme, die wir betreuen, vom Netz nehmen müssen. Für diesen Fall hatten wir festgelegt, wie wir das technisch am besten und schnellsten bewerkstelligen würden und unsere Entwickler*innen hatten das Skript dafür bereits in der Schublade. Aber würde das heute tatsächlich der Tag sein, an dem wir die Ultima Ratio umsetzen?
Was wissen wir denn? Sind unsere Systeme verwundbar? Sicher war: Es ging um zwei kritische Lücken, bewertet mit 9,2 von 10 möglichen Punkten. Offizielle Stellen wie das CERT-EU warnten eindringlich. Erste große und kleine Organisationen nahmen ihre Websites vorsorglich vom Netz. Ob es schon funktionierende Angriffe gab und falls nicht, wie lange es noch dauern würde, bis die ersten im Netz kursierten, konnte zu diesem Zeitpunkt niemand sagen.
Viele unserer Kund*innen verwalten in CiviCRM sensible Daten ihrer Mitglieder und Spender*innen, inklusive Bankverbindungen. Eine einfache Website, die ein paar Stunden nicht erreichbar ist, ist ärgerlich – gestohlene Daten hingegen wären eine Katastrophe. Nach gründlicher Abwägung fällten wir deshalb gemeinsam die Entscheidung, dass wir die Daten unserer Kund*innen nur schützen können, indem wir sie vom Netz nehmen.
Dann ging alles ganz schnell: Wir teilten uns auf und alle übernahmen, was sie am besten können. Zwischen 10:30 und 11 Uhr waren alle von uns betreuten Websites vom Netz; zum ersten Mal überhaupt. Unsere Kund*innen waren informiert (und unsere Telefone standen danach nicht mehr still).
Kurz vor 16 Uhr erschien dann das offizielle Update, die Schatzkarte zum Gold lag jetzt für alle offen im Internet. Unser Hosting-Anbieter nahm daraufhin zusätzlich alle seine Server komplett vom Netz, denn er gehört nicht zum Kreis der Eingeweihten, die das Update schon vorher bekommen. Er brauchte dann einige Stunden, um alle Systeme zu aktualisieren.
Besonderheit 3: Die Schatzkarte hing längst am Saloon
Was wir erst im Laufe des Tages erfuhren: Die Schatzkarte war da schon seit Stunden öffentlich. Um 9:41 Uhr hatte das US-Unternehmen Chainguard die Verschwiegenheitsübereinkunft mit dem PHP-Team gebrochen – ausgerechnet ein Anbieter, der sich als vertrauenswürdiger Partner für Freie Software bewirbt. Chainguard hatte das Update wie andere Anbieter vorab vertraulich bekommen. Mehr als sechs Stunden vor dem vereinbarten Termin stellten sie dann allerdings die reparierte Version ihrer PHP-Umgebung frei zugänglich ins Netz. Jeder Angreifer konnte die Reparatur nun studieren, während alle anderen noch auf das offizielle Update warteten (PHP Foundation).
Chainguards CEO begründete das damit, dass es bereits echte Angriffe gegeben hätte und die Verschwiegenheitsübereinkunft somit nicht mehr gelte (The Register). Eine zweifelhafte Aussage vor dem Hintergrund, dass funktionierende Angriffe höchstens gerüchteweise kursierten. Von offizieller Seite hieß es, dass keine funktionierenden Angriffe bekannt seien. Und selbst wenn es diese gegeben hätte, hätte die Chainguard-Lösung nur den eigenen Kund*innen geholfen; sinnvoller wäre es gewesen, auf eine frühere Veröffentlichung des offiziellen Sicherheitsupdates durch das PHP-Team zu drängen. Vielmehr drängt sich mir die Vermutung auf, dass die Firma hier einen PR-Coup gewittert hat. Der Chainguard-CEO erzählte danach stolz, sein Team habe die Lücken am Freitag zuvor mit eigener KI selbst gefunden. Diese KI muss also echt etwas ganz Besonderes sein, wenn man, um sie zu bewerben, das ganze restliche Internet potenziell nun gut informierten Angreifern ausliefert.
Die richtige Entscheidung
Wie richtig wir damit lagen, schnell alles offline zu nehmen, zeigte sich schnell. Das Sicherheitsunternehmen Ellio betreibt im Netz Fallen-Server, die Angriffe aufzeichnen. Um 10:36 Uhr registrierte es dort den ersten Angriffsversuch. Das war ziemlich genau der Moment, in dem wir abschalteten und keine Stunde nach dem Chainguard-Alleingang. Letzterer bestätigt mich zusätzlich darin, dass wir richtig gehandelt haben, auch wenn wir erst später davon gelesen haben.
Die meisten der von uns betreuten Websites waren seit rund zwölf Stunden nicht erreichbar, als in der Nacht auf Donnerstag unser Hoster die aktualisierten Server wieder online schaltete. Am Donnerstagmorgen fuhren wir dann in Ruhe noch die letzten Nachzügler hoch.
Was jetzt anders ist
Solche Tage werden häufiger. Die Lücke in PHP schlummerte jahrelang, aber mit KI wurde sie innerhalb weniger Wochen von drei Teams unabhängig voneinander entdeckt. Chainguard brauchte nach eigener Aussage sogar nur einen einzigen Abend dafür.
Und auch nach der Entdeckung hat sich das Tempo verändert. Um wieder in der Analogie zu sprechen: Früher hätte es selbst mit der Schatzkarte in der Hand lange gedauert, bis die ersten Angriffe tatsächlich erfolgreich gewesen wären. Heute sind weltweit viel mehr Schatzsuchende unterwegs und die KI stattet sie mit stärkeren Detektoren aus, als sie je ein Hacker vor ihnen hatte. Die Zeit zwischen „Hier könnte eine Lücke sein“ und „Es wird angegriffen“ schrumpft so von Wochen auf Tage oder Stunden. Was die Verteidiger mit KI können, können Angreifer eben auch.
Das Tempo zieht mit KI deutlich an und die neue Herausforderung erfordert neue Antworten. Eine davon haben wir am Mittwoch gegeben: Wir haben unsere Systeme vom Netz genommen und wir werden es wieder tun, wenn die Lage es erfordert. Der Ernstfall hat gezeigt, dass unser Plan funktioniert. Lieber schalten wir unsere Websites zwölf Stunden ab, als die Daten unserer Kund*innen hinter bekannten Sicherheitslücken online zu lassen. Auch in einer unübersichtlichen Situation mit unklaren Fakten geht Sicherheit vor – oder gerade dann!