Cybersicherheit
Teknosfera-Redaktion
Cybersicherheit

Die Patch-Ära läuft jetzt im Maschinentempo – Quartalszyklen haben ausgedient

Zwei mit KI entdeckte Lücken in PHP versetzten Regierungen und Firmen in Alarm. Die Lehre ist nicht Panik: Patch-Prozesse für menschliche Zeitpläne passen nicht mehr zum Tempo der Angreifer.

Veröffentlicht
25. Oktober 2026
Lesezeit
4 min
Kategorien
Cybersicherheit

KI-generiertes Bild

Was passiert, wenn es billiger wird, einen Fehler zu finden, als ihn zu beheben? Wir haben es gerade live erlebt, und es war kein schöner Anblick. Regierungen nahmen Websites vom Netz, und die Leute, die die Rohrleitungen des Internets betreiben, verbrachten die Woche im Triage-Modus.

Kurz gefasst: Zwei kritische Lücken in PHP, das laut AFP einen großen Teil der Websites weltweit antreibt, wurden mit KI-Modellen entdeckt. Wie L'Express berichtet, gingen Regierungsseiten in Europa und anderswo vorsorglich offline, während die Betreiber hastig patchten. Zwei Sicherheitsfirmen, Calif und Wiz, gaben an, die Fehler unabhängig voneinander gefunden zu haben; Wiz erklärte, Modelle von OpenAI und Google genutzt zu haben. Die Fehler steckten seit Jahren im Code.

Unserer Ansicht nach sind die Lücken selbst weniger wichtig als das, was sie zeigen. Die Entdeckung läuft inzwischen im Maschinentempo. Die meisten Organisationen patchen weiterhin im Menschentempo.

Beängstigend ist nicht der Fehler, sondern die Uhr

Michael Daniel, Präsident der Cyber Threat Alliance und früher Cybersicherheitskoordinator des Weißen Hauses, nannte der AFP die Zahl, die uns hängengeblieben ist. Früher dauerte es ein bis zwei Monate, bis ein Proof of Concept auftauchte, und noch einmal ein bis zwei Monate, bis er in Exploit-Kits landete. Heute, sagt er, werde das in Stunden oder Tagen gemessen.

Was das für einen Quartals-Patchzyklus bedeutet, liegt auf der Hand. Schrumpft der Abstand zwischen dem Bekanntwerden einer Lücke und ihrer Ausnutzung auf Stunden oder Tage, ist ein Prozess mit monatlichen Wartungsfenstern aus unserer Sicht die Entscheidung, angreifbar zu bleiben. Die von Distributique zusammengefasste Reuters-Recherche nennt VulnCheck-Daten, wonach sich die Zahl entdeckter Schwachstellen binnen eines Jahres verdoppelt. Ein doppeltes Aufkommen bei kollabierendem Reaktionsfenster ist eine Zwickmühle, die sich vermutlich nicht mit mehr Personal lösen lässt.

Fair bleiben müssen wir bei den Einschränkungen allerdings. Daniel weist darauf hin, dass historisch nur fünf bis sechs Prozent der Schwachstellen ausgenutzt wurden, und nichts deutet darauf hin, dass dieser Anteil steigt. Zu dieser konkreten Lücke widersprechen sich die Berichte. Von Distributique zitierte Forscher sagten, zum Zeitpunkt der Reuters-Recherche sei kein funktionierender Exploit bestätigt gewesen. L'Express wiederum berichtet, Technologiefirmen hätten gewarnt, einige Hacker nutzten die Lücken bereits aus. Das können wir von hier aus nicht entscheiden. Unsere Einschätzung: Es ist zuallererst ein Tempoproblem, und zu behaupten, das Internet brenne bereits, wäre übertrieben. Es abzutun wäre schlimmer.

„Wochenlang alles testen“ war ein Luxus, keine Strategie

Der unbequemste Gedanke in Daniels Interview betrifft die Risikobereitschaft. Die meisten Unternehmen fuhren das, was er eine Nulltoleranz gegenüber Ausfällen nennt, und testeten Patches deshalb gründlich. Diese Zeit hätten sie nicht mehr, argumentiert er. Wenn ein Patch mit einem Prozent Wahrscheinlichkeit etwas kaputtmacht, ein Angriff aber 50 Millionen Dollar kosten könnte, verschiebt sich die Abwägung.

Wir halten ihn für im Recht, auch wenn das viele IT-Abteilungen nicht gern hören. Langsames, sorgfältiges Patchen war rational, solange Ausnutzung langsam war. Jetzt ist die Kosten des Wartens das größere Risiko. In der Praxis heißt das drei unspektakuläre Dinge. Erstens ein genaues Inventar dessen, was man betreibt und was davon aus dem Internet erreichbar ist. Zweitens automatisierte Test- und Deployment-Pfade, die eine Korrektur schnell ausliefern können. Drittens temporäre Gegenmaßnahmen für den Fall, dass ein Patch nicht sofort ausgerollt werden kann. Das ist ungefähr die Checkliste aus dem Distributique-Beitrag, und nichts davon braucht KI. Es braucht Disziplin, und die ist schwerer zu haben.

Die eigentlichen Verlierer sind kleine Organisationen. Daniels Rat an sie ist deutlich: die Organisation so aufstellen, dass sie Herstellerupdates so schnell wie möglich übernehmen kann. Wer eine verwaltete Plattform nutzt, wählt Anbieter dann vor allem danach aus, wie schnell sie patchen.

Technische Schulden sind die eigentliche Geschichte, KI ist der Inkassodienst

Daniel spricht davon, dass die „technischen Schulden fällig werden“. Die impliziten Kosten für den Weiterbetrieb alter Software tauchen in keiner Bilanz auf, bis es zu einem Vorfall wie diesem kommt. Rob Joyce, früher Cybersicherheitsdirektor der NSA, nannte es den „großen reinigenden Waldbrand alter Software“. Beide Bilder überzeugen uns.

Es gibt auch eine hoffnungsvolle Lesart. Daniel erwartet, dass KI-Werkzeuge auf Software angewendet werden, bevor sie ausgerollt wird, sodass neuer Code mit weniger Lücken startet. Jason Clinton, Sicherheitsmanager bei Anthropic, schrieb auf X, es werde viel schlimmer, bevor es besser werde, und man müsse etwa 18 Monate durchhalten, so 01net. Das ist eine Prognose, keine Tatsache, und sie stammt von einem Unternehmen, das diese Modelle baut. Die Logik ist dennoch plausibel: Die Verteidiger bekommen irgendwann dieselben Werkzeuge.

Eine weitere Warnung betrifft das Rauschen. Daniel räumt offen ein, dass viele von KI gemeldete Funde Fehlalarme sind oder in Software stecken, die nie mit dem Internet verbunden ist. Der Engpass scheint die Triage zu sein, nicht die Entdeckung.

Unser Fazit

Behandeln Sie das nicht als PHP-Geschichte. Sehen Sie darin einen Stresstest Ihrer Patch-Pipeline, und fragen Sie sich ehrlich, wie lange ein kritischer Fix diese Woche bei Ihnen gedauert hätte. Lautet die Antwort „Wochen“, ist das das Projekt für das nächste Quartal, nicht für den nächsten Patchzyklus. Erfassen Sie, was Sie betreiben, automatisieren Sie das Deployment, akzeptieren Sie ein kleines Ausfallrisiko und schalten Sie Software ab, die nur aus Trägheit am Leben gehalten wird. Die Flut, die Daniel beschreibt, kommt ohnehin. Die einzige Wahl ist, ob Sie einen Überlauf gebaut haben.

Diskussionsthemen

Noch keine Themen: Eröffne das erste.

Weitere Artikel