Editionsgeschichte

PHP2Shell: Wie KI half, alte Fehler in PHP aufzudecken, und warum Schweizer Anbieter ihre Dienste bewusst vom Netz nahmen.

Der Mittwoch, an dem die Websites verschwanden

Am Mittwoch, 21. Oktober, um 15:45 nahm der Basler Hoster cyon sein Webhosting vom öffentlichen Netz. My.cyon, Webmail, die Managed- und Agency-Server und der Sitebuilder gingen mit. Die Postfächer nahmen weiter Nachrichten an. Die Websites waren einfach weg.¹

SRF nannte später die Grössenordnung. Cyon hostet über 100’000 Websites, für Vereine, KMU, private Blogs und Konzerne, und hatte sie alle für ein paar Stunden vom Netz genommen.² Bexio, die Buchhaltungssoftware, mit der viele Schweizer Kleinbetriebe ihren Tag bestreiten, hatte schon um 11:08 am Vormittag pausiert.³ Der Kanton Basel-Stadt schaltete am Abend seine Websites ab. Teile der ETH Zürich taten dasselbe.⁴⁵

Die Reaktionen kamen erwartungsgemäss. Warum geht ihr offline? Beweist das nicht schlechte Planung? Ist WordPress schuld? Hat die KI das Internet kaputtgemacht?

Die Fakten zeigen in die andere Richtung. Der Unterbruch war sichtbar. Der Einbruch, den er verhindern half, wäre es nicht gewesen.

KI-gestützte Forschung half, schwere Fehler aufzudecken, die seit Jahren in PHP steckten. Besonnenes Isolieren und Patchen half, einen echten Notfall zu bewältigen. Und wo die Offenlegung misslang, machten Menschen die Fehler, nicht die Technik, mit der man die Lücken fand.

Was tatsächlich kaputt war

Der Fehler lag unterhalb der Anwendung.

PHP ist die Sprache, auf der ein grosser Teil des Webs läuft. Am 21. Oktober veröffentlichte das PHP-Projekt die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35, um zwei kritische Schwachstellen zu schliessen. Beide sind nach CVSS v4.0 mit 9,2 von 10 bewertet. Die frühen Gerüchte von 10,0 waren falsch.⁶⁷

Die erste, CVE-2026-109618, betrifft eine Speicherbeschädigung. Erreicht eine Anfrage genau im falschen Moment das Speicherlimit von PHP, kann PHP halb initialisierte Daten zurücklassen und sie später als gültig behandeln. Unter Apache mit mod_php lässt sich das ohne Anmeldung auslösen, bevor überhaupt Anwendungscode läuft. Die Ausführung von fremdem Code wurde mit Standardeinstellungen vorgeführt und unter PHP-FPM über Pfade in der Anwendung bestätigt.⁶

Die zweite, CVE-2026-109619, entsteht durch veralteten Zustand nach einem fatalen Fehler. Speicher, der zu einer Anfrage gehörte, kann von einer späteren Anfrage im selben Worker benutzt werden. Bestätigt sind ein Use-after-free und ein Absturz des Workers; der Melder führte zudem Codeausführung gegen eine reale Anwendung unter mod_php vor.⁶

Beide sitzen in der Speicherverwaltung und der Fehlerbehandlung, also dort, wo fast jede Anfrage vorbeikommt. Die Ursache liegt damit unter dem CMS, dem Theme, dem Plugin und dem meisten Anwendungscode. Das heisst nicht, dass jede Installation gleich angreifbar war. Das hängt von der Einbindung, den Versionen und den tatsächlichen Anfragepfaden ab.⁶⁸

Wer eine Website betreibt, sollte WordPress, Themes und Plugins trotzdem wegen ihrer eigenen Lücken aktualisieren. Doch WordPress durch ein anderes PHP-Produkt zu ersetzen, hätte diese Fehler im Kern nicht beseitigt. Richtig war, die Laufzeit zu patchen und zu prüfen, nicht ein CMS an den Pranger zu stellen.⁶⁸

Ein Problem, das man 2024 schon sah

Die aufschlussreiche Geschichte beginnt 2024, nicht an einem Mittwoch mit Ausfällen.

2024 wurde PHP zum ersten Mal seit Jahren extern auf Sicherheit geprüft. Die Sovereign Tech Agency bezahlte das Audit, Quarkslab führte es durch. Beim Beheben eines Befunds stiess ein PHP-Kernentwickler auf erste Anzeichen des Speicherproblems. Ein Angriff wurde durchgedacht, ein konkreter Weg aber nicht gefunden.⁶

Jede mögliche Korrektur hatte ihren Preis. Die eine brach die Abwärtskompatibilität. Die andere schuf neue Risiken für Denial-of-Service. Eine dritte verlangte Änderungen an Erweiterungen von Dritten, die kaum zu koordinieren schienen. Ein kleines Team, das im Konsens entscheidet, kam zu keinem Entschluss, und die Arbeit stockte und begann über Monate immer wieder von vorn.⁶

Die PHP Foundation hat das nicht beschönigt. Sie nannte die Verzögerung ein strukturelles Versagen, verursacht durch ihren Entscheidungsprozess und durch zu wenige Leute, die den Kern wirklich kennen.⁶ Sicherheitsarbeit heisst nicht: Fehler finden, eine Zeile ändern, ausliefern. Manche tiefen Fehler verlangen einen Umbau und sorgfältige Tests über mehrere Versionen.

Dann veränderte 2026 die Beweislage. Im Mai gründete die Foundation ein Ecosystem Security Team. Am 30. Juli begann die Sicherheitsfirma Calif im Programm Patch the Planet ein Audit von PHP. Am 11. August meldete der Calif-Forscher Ryan A eine bedingungslose Codeausführung mit derselben Ursache, und OpenAI meldete unabhängig davon dasselbe. Wiz meldete am 24. August eigene Angriffsketten. OpenAI lieferte am 18. September weitere Angriffswege.⁶⁸

Die KI hat den fehlerhaften Code nicht geschrieben. KI-gestützte Forschung hat gezeigt, wie schwer und wie dringend ein Fehler war, den es längst gab.

Wo die KI half, und was sie nicht tat

KI-gestützte Analyse veränderte drei Dinge. Modelle halfen den Forschenden, sich in einer grossen, gewachsenen Laufzeit aus nativem Code zurechtzufinden, deren Fehlerbehandlung schwer zu durchschauen ist. Angriffsideen liessen sich über viele Konfigurationen schneller ausprobieren, verwerfen und testen. Und die Vorführungen machten das Risiko für die Release-Verantwortlichen greifbar: Aus einer theoretischen Speichergefahr wurde ein beobachteter Weg zur Codeausführung.⁶⁸⁹

Laut PHP Foundation nutzte Calif ein führendes Modell von OpenAI. Wiz beschreibt solche Modelle im Zusammenspiel mit erfahrenen Forschenden und eigenen Systemen. Die Maintainer berichten zudem von einem früheren Scan mit Claude Mythos von Anthropic und von Werkzeugen von OpenAI bei der Triage. Das war nicht das Wunder einer einzelnen Marke. Die Modelle erweiterten Fachteams. Sie ersetzten sie nicht.⁶⁸⁹

Was die KI nicht tat, zählt ebenso. Sie schrieb den verwundbaren Code nicht; der war Jahre alt. Sie entschied weder über die Triage noch über den Patch noch über die Kompatibilität. Laut Foundation traf jede Entscheidung ein Mensch, und an jedem Patch arbeitete ein Mensch.⁶ Sie schnürte keine Pakete für Distributionen, baute keine Firewall-Regeln und spielte bei Hostern nichts ein.¹⁰⁹ Und sie bewies nicht, dass kein Angreifer früher Bescheid wusste.¹¹

Der ehrliche Schluss lautet also nicht, dass KI die Verteidigung mühelos macht. Die KI erhöhte die Chance, dass Verteidiger ein altes, verborgenes Risiko finden und belegen. Sie senkt aber auch den Aufwand für Angreifer. Sichere Korrekturen in den Betrieb zu bringen, bevor billige Angriffsfähigkeit sich verbreitet, ist die Gestaltungsaufgabe des nächsten Jahrzehnts.

Das Fenster der Verteidiger

Ein leistungsfähiges Modell kann in Stunden einen brauchbaren Befund liefern. Eine weit verbreitete Laufzeit braucht Wochen, bis sie gepatcht, getestet, verteilt und eingespielt ist. Der Abstand zwischen diesen beiden Uhren ist das Fenster der Verteidiger.

Schliesst sich das Fenster, bevor die Betreiber eine praktische Korrektur haben, wird selbst ein verantwortungsvoll gemeldeter Befund zur akuten Gefahr. Der Fall PHP zeigt beides: den Wert einer frühen Warnung und wie zerbrechlich die Koordination wird, wenn eine Vorführung oder ein verräterisches Binärpaket das Embargo zu früh verlässt.⁶⁹

OpenAI hat 1 Milliarde Dollar an vergünstigtem Zugang zu einem Sicherheitsmodell für Verteidiger an vorderster Front angekündigt. Das ist eine Zusage für die Zukunft. Es ist kein Geld, das bereits an die PHP Foundation geflossen oder für diesen Vorfall ausgegeben worden wäre.⁹

Ein guter Fund bemisst sich nicht daran, dass kein sichtbarer Notfall entsteht. Er bemisst sich an den künftigen Einbrüchen, die geprüfte Korrekturen verhindern. Die lassen sich schwerer zählen als Ausfälle, und man sollte keine erfundene Zahl daraus machen.

Vier Ereignisse, nicht ein Leck

Die koordinierte Veröffentlichung war auf Donnerstag, 22. Oktober, 14:00 UTC angesetzt. Am Dienstag, 20. Oktober, gegen 15:00 UTC, kursierten die beiden CVE-Nummern mit einer falschen Bewertung von 10,0. Technische Details sickerten nicht durch, und wer dieses erste Leck verursachte, ist bis heute unbekannt. PHP zog die Vorankündigung auf 19:30 UTC vor und verlegte die Veröffentlichung auf Mittwoch, 21. Oktober, 14:00 UTC.⁶

Gegen 20:00 UTC am selben Abend veröffentlichte Calif versehentlich ein Video, das seinen Proof of Concept gegen mehrere Ziele zeigte. Es wurde gelöscht, doch Kopien machten die Runde, und laut Foundation beschleunigte das Video die Entwicklung weiterer Vorführungen. Auch Hinweise zur Abwehr, die gegen 23:00 UTC an einige Betreiber kritischer Infrastruktur gingen, könnten durchgesickert sein.⁶

Am 21. Oktober um 07:41 UTC, mehr als sechs Stunden vor der Veröffentlichung, stellte Chainguard Container-Images mit den korrigierten Binärdateien online. Die Foundation kritisierte das: Nun konnte jeder die Korrektur studieren, während alle anderen warteten. Der Chef von Chainguard sagte, man habe bewusst früh veröffentlicht, und verwies auf Berichte über aktive Ausnutzung.⁶¹² Die Abwägung ist in beide Richtungen echt. Die Quellen entscheiden sie nicht.

Und das Threat-Intelligence-Team von Amazon fand in seinen Honeypots schon am 17. Oktober, was es als Angriffsversuch einstufte, also vor jedem öffentlichen Leck. Ob solche Versuche gegen echte Systeme funktioniert hätten, ist offen.¹¹

Das sind vier verschiedene Ereignisse mit vier verschiedenen Schlüssen. «Ein Mensch hat alles verraten» ist keine Erklärung von Ursachen. Und keines davon zeigt, dass die KI die Fehler selbst verursacht hat.

Dreissig Stunden in der Schweiz

Alle Zeiten in diesem Abschnitt sind Schweizer Sommerzeit (MESZ, UTC+2), so wie die Betreiber sie veröffentlicht haben. ENISA nennt für die korrigierten Versionen 13:40 UTC, also 15:40 Schweizer Zeit. Viele Anbieter richteten sich nach den angekündigten 16:00.¹⁰¹³¹⁴

Das ist ein Register dessen, was die Betreiber öffentlich sagten, keine Rangliste.^{11531617181920142122} Die Betreiber haben unterschiedliche Produkte, Supportmodelle und alte PHP-Versionen. Eine kurze Abschaltung beweist keinen besseren Schutz. Online zu bleiben beweist keine Nachlässigkeit.

Als Balken gezeichnet, sehen die Fenster wie eine Rangliste aus: bexio 20 h 49 min, cyon rund 12 h 15 min, MvA 6 h 09 min für seine PHP-Webserver, Onlime rund 46 Minuten.^13162014 Sie sind keine. Bexio ist eine Geschäftsanwendung. Cyon betreibt eine grosse geteilte Hosting-Landschaft. MvA hatte Pakete nach PHP-Version gestaffelt. Onlime hatte vorher schon einen Geofence gesetzt. Ein kürzerer Balken ist keine Sicherheitsauszeichnung, ein längerer keine Fahrlässigkeit.

Vom Netz gehen, online bleiben

Das Statusprotokoll von bexio eröffnet den Notfall um 11:08 und nennt die kritische PHP-Bedrohung. Betroffen waren Website, Office, Cockpit, Lohn, API und Bankfunktionen. Der Vorfall wurde am nächsten Morgen um 07:57 geschlossen, das Update war eingespielt. Später erklärte die Firma, ihre eigenen Prüfungen hätten keinen unberechtigten Zugriff ergeben. Das ist die Aussage des Betreibers, keine unabhängige Prüfung.³¹⁶²³

Cyon wartete auf Sicherheitspakete, die auf die eigene Infrastruktur abgestimmt waren, samt Backports für ältere PHP-Versionen, statt die Quelltext-Releases als Grund zum Wiederanlaufen zu nehmen.¹¹⁵ Gründer David Burkhardt sagte gegenüber SRF, die Massnahme sei drastisch gewesen, aber eine Abwägung: Bei gehackten Websites stünden Jobs auf dem Spiel, Kundendaten könnten abfliessen, ganze Systeme zerstört werden.²

Onlime beschränkte um 14:50 den Webzugriff auf die Schweiz, Liechtenstein und Österreich, nahm um 16:00 die Webserver vom Netz, patchte zwischen 16:20 und 16:45 und war um 16:46 wieder vollständig online.¹⁴²¹ MvA trennte um 15:35 alle Webserver. Aktuelle PHP-Versionen kamen ab 18:17 zurück, ältere um 21:44, die Plesk-Oberflächen erst am Folgetag.²⁰ Der eine hatte eine schnelle Paketquelle. Der andere wartete auf Backports für alte Versionen. Keiner von beiden beweist, dass eine Finanzanwendung in 46 Minuten zurück sein müsste.

Andere blieben online. Hosttech sagt, sein Werkzeug Imunify360 habe am 20. Oktober automatisch Schutzmassnahmen gesetzt, die offiziellen Korrekturen seien ab etwa 16:00 am 21. Oktober eingespielt und über Nacht abgeschlossen worden, ohne allgemeine Abschaltung. Hosttech hält auch fest, dass eine zusätzliche Schutzschicht kein Update der Laufzeit ersetzt.¹⁷ METANET härtete zuerst die Servereinstellungen und patchte dann in Etappen, teils wartend auf Pakete von CloudLinux.¹⁸¹⁹ Green fuhr ein 12-stündiges Wartungsfenster von 18:05 bis 06:05 und bestätigte die letzten Patches um 10:16. Erwartet wurden kurze Unterbrüche einzelner Systeme, kein Ausfall von 12 Stunden.²² Ein Wartungsfenster ist keine Ausfallzeit.

Öffentliche Institutionen standen vor derselben Wahl. Der Krisenstab von Basel-Stadt entschied am Mittwochabend, die kantonalen Websites abzuschalten. Am nächsten Tag um 11:45 kehrten gepatchte Seiten zurück, und es war kein sicherheitsrelevanter Vorfall registriert.⁴ Die zentrale Website der ETH Zürich und Staffnet waren nicht direkt betroffen; einzelne WordPress- und andere PHP-Seiten von Einheiten mussten abgeschaltet und behoben werden.⁵ «Bisher kein Vorfall registriert» ist eine datierte Beobachtung, kein forensischer Beweis.

Versuche sind keine Einbrüche

Amazon verzeichnete am 17. Oktober einen mutmasslichen Versuch und am 21. Oktober weitere aus mehr als einer Quelle, teils vor der breiten Veröffentlichung. Ob diese Angriffe gegen echte Ziele Erfolg hätten, sei unklar.¹¹

Imperva zählte in den ersten 24 Stunden 482’342 Anfragen, 122’311 Angriffssitzungen, 21’998 angegriffene Websites und 103 Länder.¹³ Das ist automatisierte Aufmerksamkeit in echtem Umfang. Es ist keine Zahl von Einbrüchen, und Imperva sagt das selbst.

Cloudflare schaltete am 21. Oktober um 03:02 UTC Standardschutz für seine Firewall-Kunden ein und sah zu, wie Angreifer ihre Angriffe abwandelten, um daran vorbeizukommen. Die Botschaft ist klar: PHP trotzdem patchen.²⁴

Für die Schweiz sagte das Bundesamt für Cybersicherheit am 22. Oktober gegenüber SRF, ihm seien keine Angriffe in der Schweiz bekannt, die diesen Schwachstellen zugeordnet werden könnten, und warnte, unerkannte oder nicht gemeldete Fälle könnten noch auftauchen.² «Keine bekannten Fälle» heisst nicht «null Einbrüche».

Die anderen Schweizer Zahlen verlangen dieselbe Sorgfalt. Die «über 100’000 Websites offline» von SRF sind der Bestand von cyon, keine Zählung aller Schweizer Websites.² Am 22. Oktober um 05:37 zeigte ein öffentlicher Scanner 16’128 von 466’383 Schweizer Websites als betroffen an, 3,5 Prozent. 437’288 landeten in einem einzigen Topf mit der Aufschrift gepatcht oder kein PHP, der zwei sehr verschiedene Zustände vermischt.²⁵ Und der PHP-Anteil von 69,3 Prozent bei W3Techs gilt nur für Websites, deren serverseitige Sprache es erkennt. In Nacherzählungen wurde daraus «70 Prozent des Internets waren verwundbar».²⁶

Es gibt keinen ehrlichen Schaden für das ganze Land in Franken, keine Zahl gehackter Schweizer Websites und keinen Sicherheitssieger unter ungleichen Diensten. Diese Unbekannten sind ein Forschungsprogramm, keine Lücken zum Auffüllen.

Warum WordPress beschuldigt wurde

WordPress ist so verbreitet, dass ein PHP-Problem als eine WordPress-Seite erscheint, die nicht läuft. Man sieht die Anwendung, nicht den Interpreter darunter. Der Ruf, das CMS zu verlassen, ist darum verständlich. Technisch ist er falsch. Wiz zeigte die Angreifbarkeit an WordPress, Drupal und Joomla, während der Fehler im PHP-Kern lag.⁸ Auch eine gut gepflegte Anwendung kann auf einer ungepatchten Laufzeit laufen.

Die bessere Frage ist nicht, welches CMS nie Lücken hat. Das kann keines versprechen. Sie lautet: Wer ist für die unteren Schichten zuständig, wie schnell wird gepatcht, werden ältere Versionen mitgetragen, welcher Schutz am Rand und welche Notfallpläne bestehen, und wie wird kommuniziert, wenn eine Abhängigkeit versagt? WordPress auf gut betreutem PHP kann weniger Risiko tragen als ein Eigenbau auf vernachlässigtem Unterbau.

Eine Firewall verschafft Zeit; sie ersetzt die Korrektur nicht.²⁴ Und «Es wurde nichts gemeldet, also war es übertrieben» verwechselt das Fehlen eines beobachteten Einbruchs mit dem Fehlen einer Gefährdung.

Wie man einen Anbieter fair beurteilt

Einen Unterbruch kann man in Minuten, verlorenen Verkäufen und verspäteten Rechnungen messen. Die Angriffe, die nicht stattfanden, weil ein System isoliert war, misst man kaum. Dieses Ungleichgewicht drängt das öffentliche Urteil dahin, Eindämmung für Versagen zu halten und unsichtbares Risiko für Können.

Wer einen Tag lang keine Rechnungen stellen konnte, hat echten Schaden erlitten. Doch ein Anbieter, der seine Kunden wissentlich einer Übernahme ihrer Server ohne Anmeldung aussetzte, nur um diesen Unterbruch zu vermeiden, hätte weit Schlimmeres anrichten können. ENISA und ihre europäischen Partner rieten zur vorübergehenden Trennung vom öffentlichen Netz, wo Patches nicht rasch einzuspielen waren.¹⁰

Ein Anbieter mit glaubwürdigem, mehrschichtigem Schutz kann zu Recht online bleiben, wie hosttech berichtet. Ein Anbieter ohne geprüften Schutzschild oder mit offen liegenden alten Laufzeiten kann zu Recht vom Netz gehen, wie cyon und bexio.¹⁰¹³¹⁷ Das Versagen liegt darin, blind zu wählen oder «geschützt» zu behaupten, ohne eine Erklärung, die sich prüfen lässt.

Die Frage lautet also nicht «Warum seid ihr vom Netz gegangen?», sondern «Welche sicherere Alternative hattet ihr, und wie schnell habt ihr die Korrektur geprüft?». Man frage nach dem letzten bekannten Zeitpunkt der Gefährdung, nach dem Schutz vor dem Patch, nach der Herkunft der Pakete, nach der Art der Prüfung, ob alte Worker neu gestartet wurden, welche Kunden betroffen waren und was die Protokolle danach zeigten. Die Dauer des Ausfalls ist eine Zeile in dieser Prüfung, nicht ihre Schlussnote.

Für die nächste Krise braucht es das als stehendes Drehbuch: eine Zuordnung jeder Anwendung zu ihrer PHP-Laufzeit, eine Notiz, wer die Isolation wann und warum beschloss, geprüfte Backport-Kanäle für ältere Versionen, Protokolle aus der Zeit vor dem ersten bekannten Angriffsversuch und eine öffentliche Nachbetrachtung nach Komponenten.⁶¹⁰¹⁸

Zwei Budgets, nicht eines

Die Chronik von PHP ist ein ungewöhnlich offener Fall öffentlicher digitaler Infrastruktur, die von zu wenigen Menschen getragen wird. Ein Fehler in komplexer Software ist nichts Aussergewöhnliches. Beunruhigen sollte alle, die von PHP abhängen, wie ein Sicherheitsproblem an Kompatibilitätsfragen hängen bleiben konnte, während der Wert, der darauf aufgebaut wird, weiter wuchs. Die Foundation bittet Firmen, Hosting-Plattformen und öffentliche Stellen, ihre Sicherheitsarbeit im Mass ihrer Abhängigkeit zu finanzieren.⁶

Die KI hat nicht einfach gefunden, was Menschen übersehen hatten. Sie hat das Tempo der Funde erhöht und ein Missverhältnis bei der Kapazität zum Beheben offengelegt. Die Foundation veröffentlichte seit dem 1. Juli 15 CVEs und arbeitete sich durch mehr als 100 Meldungen, die ungültig, doppelt oder nicht nachvollziehbar waren.⁶ Das ist ein echtes Kapazitätsproblem, keine Fussnote.

Ein ernsthaftes Programm hat darum zwei Budgets. Das eine bezahlt Zugang zu Modellen und Sicherheitsforschung. Das andere bezahlt Maintainer, Testinfrastruktur, die Abstimmung mit den Distributionen und unabhängige Prüfung. Das eine ohne das andere füllt nur einen Posteingang.

Methode und Grenzen

Diese Field Note beruht auf öffentlichen Quellen, wie sie am 23. Oktober 2026 gegen Mittag Schweizer Zeit vorlagen: Aussagen der Maintainer, Warnungen von Behörden, Telemetrie von Anbietern, Statusseiten und Berichterstattung. Sie scannt keine Systeme, stellt keine Angriffe nach, untersucht keine Einbrüche und zertifiziert keinen Anbieter. Aussagen von Betreibern werden als deren eigene Darstellung wiedergegeben. Statusfenster, Wartungsfenster und Ausfallzeiten bei Kunden bleiben getrennt.

Offen bleibt: wer das erste Leck am 20. Oktober verursachte; ob die Versuche vom 17. Oktober Systeme im Betrieb erreichten; wie viele Einbrüche, falls überhaupt, bestätigt sind; welche Ausfallzeit einzelne Kunden tatsächlich erlebten; und ob die frühe Veröffentlichung von Chainguard mehr Menschen schützte, als sie gefährdete.⁶¹¹¹² Eine Aussage, die Marcel Salathé auf LinkedIn zugeschrieben wird, ist hier nicht zitiert, weil sich der ursprüngliche Beitrag nicht überprüfen liess. Sollten geprüfte Zahlen zu Einbrüchen oder Nachbetrachtungen der Anbieter erscheinen, gehören sie in einen datierten Nachtrag, nicht in eine stille Überarbeitung.

Der Ausfall war sichtbar

Das erste Missverständnis dieser Krise ist, einen bewusst abgeschalteten Dienst für einen wehrlosen zu halten und einen, der online blieb, für einen sichereren. Das zweite ist, aus einer KI-gestützten Offenlegung zu schliessen, die KI habe den Fehler geschaffen. Das dritte ist, über WordPress zu reden, wenn der verwundbare Code in PHP selbst lag.⁶¹⁰⁸

Die schwierigere Wahrheit ist die interessantere. Fachleute sahen die Warnzeichen zwei Jahre vor der Krise, doch ihnen fehlten der Angriffsweg und die Kapazität, eine schwierige Korrektur zu Ende zu bringen. KI-gestützte Verteidiger machten aus dem undurchsichtigen Risiko einen Beleg. Menschen bauten und lieferten die Patches. Hoster und Behörden entschieden, wer online bleiben sollte, während sich die Korrekturen verbreiteten. Und Menschen machten Fehler bei der Offenlegung, während Angreifer vielleicht schon tasteten.⁶⁹¹¹¹²

Maschinen haben kein hilfloses Internet gerettet, und sie haben kein sicheres ruiniert. Das Finden wird schneller, die Abstimmung schwieriger, und kompetente menschliche Verantwortung wird mehr wert, nicht weniger. Die Antwort ist nicht der Rückzug von der KI. Sie besteht darin, KI-gestützte Verteidigung so gut zu finanzieren und zu führen, dass sich das nächste Fenster der Verteidiger öffnet, bevor die Lichter ausgehen müssen.

Eine verantwortungsvolle Abschaltung ist ein Akt des Schutzes, kein Beweis des Versagens.

Quellen