Die wichtigsten Erkenntnisse
- KI-Modelle wie Anthropics Claude Mythos decken schwerwiegende Schwachstellen in den wichtigsten Betriebssystemen und Browsern auf. Dadurch schrumpfen die Zeitfenster für Exploits, während herkömmliche, manuelle Patchprogramme überfordert werden.
- Bei großem Maßstab versagen herkömmliche Patch-Workflows. Wer sich allein auf Schwachstellenscanner, lineare ticketbasierte Genehmigungen oder Endpoint-Tools mit eingeschränkter Transparenz verlässt, erzeugt Verzögerungen, blinde Flecken und eine wachsende Gefährdung, wenn Anzahl und Taktung der CVEs sprunghaft ansteigen.
- Kontinuierliche Triage, risikobasierte Priorisierung, ringbasierte Bereitstellung mit Rollback und eine Verifikation im geschlossenen Regelkreis sind die einzige Möglichkeit für IT- und Sicherheitsteams, Schritt zu halten, wenn Angreifer und Verteidiger gleichermaßen KI nutzen, um schneller voranzukommen.
Am 7. April gab Anthropic bekannt, dass sein Modell Claude Mythos Preview autonom Tausende Schwachstellen mit hoher und kritischer Schwere in allen wichtigen Betriebssystemen und allen wichtigen Webbrowsern identifiziert hatte. Über 99 % davon waren am Tag der Veröffentlichung noch ungepatcht.
Zwei Wochen später, am 21. April, erklärte Mozilla, dass das Unternehmen dasselbe Modell eingesetzt hatte, um 271 Schwachstellen in der neuesten Firefox-Version zu finden und zu beheben. Mozillas eigene Einschätzung: „Bisher haben wir keine Kategorie oder Komplexität von Schwachstellen gefunden, die Menschen erkennen können, dieses Modell aber nicht.“
271 ist nur die erste Welle. Chrome, Edge, Windows, macOS, Linux, FreeBSD – die 17 Jahre alte Schwachstelle zur Remotecodeausführung in FreeBSD, die Anthropics Red Team offengelegt hat (CVE-2026-4747), ist ein frühes Beispiel für das, was kommt. Jeder Anbieter unter dem Dach von Anthropics Project Glasswing ist in der Lage, Fehlerbehebungen in einem Tempo zu veröffentlichen, das die Branche bisher nicht erlebt hat. All diese Fehlerbehebungen werden zu öffentlichen CVEs mit verfügbaren Patches – und landen damit am selben Ort: in Ihrer Umgebung.
Auch die Geschichte der Eindämmung hat einen Riss. Am 21. April berichtete Bloomberg davon, dass eine mit Discord verbundene Gruppe über die Umgebung eines Drittanbieters unbefugten Zugriff auf Mythos erlangt hatte. Anthropic zufolge ging die Aktivität nicht über diesen Anbieter hinaus. Unabhängig davon, ob eine ähnliche Fähigkeit bereits in den Händen von Angreifern ist: Der defensive Handlungsspielraum ist kürzer, als die Ankündigung vom 7. April vermuten ließ.
Mythos kam in eine Welt, die sich bereits in diese Richtung bewegte. CrowdStrikes Global Threat Report 2026 dokumentierte für 2025 einen Anstieg KI-gestützter Angriffe um 89 % gegenüber dem Vorjahr. Diese Entwicklung begann vor Mythos.
Nennen wir das eine Patch-Apokalypse. Gemeint ist die ganz praktische operative Variante, bei der Umfang und Taktung öffentlicher CVEs mit verfügbaren Patches bald schneller zunehmen werden, als die meisten IT- und Sicherheitsteams derzeit arbeiten können.
NIST spürt die Auswirkungen der Patch-Apokalypse bereits. Im April kündigte die Behörde als Reaktion auf einen Anstieg der Einreichungen um 263 % eine umfassende Änderung des Betriebs der National Vulnerability Database (NVD) an. NIST wird nicht mehr alle eingereichten Schwachstellen detailliert anreichern, sondern dies nur noch für Schwachstellen tun, die ein hohes Risiko aufweisen – etwa solche im Katalog der bekannten ausgenutzten Schwachstellen der CISA oder solche, die kritische Regierungssoftware betreffen. NIST wird sich auf CVE Number Authorities (CNAs) wie Ivanti stützen, statt eine eigene unabhängige Bewertung durchzuführen.
Seit der Ankündigung höre ich von Kunden und Kollegen drei Varianten derselben Reaktion. Alle drei sind Abwandlungen eines Programms, das für eine langsamere Welt entwickelt wurde.
„Wir haben einen Schwachstellenscanner“
Qualys, Rapid7 und Tenable leisten gute Arbeit bei der Erkennung von Schwachstellen. Scanner finden, kennzeichnen, bewerten und listen auf. Bereitstellung, Verifikation, Umgang mit Neustarts und Rollback gehören nicht zu ihrem Aufgabenbereich. Diese Arbeit muss trotzdem irgendwo erledigt werden. In den meisten Programmen geschieht das in einem separaten Tool, mit einem separaten Team und in einem separaten Takt.
Wenn das Zeitfenster für Exploits inzwischen nur noch Stunden beträgt und die Glasswing-Warteschlange den Rückstand bald verdoppelt, ist ein Scanner, der 587 kritische Schwachstellen ausgibt und die Liste an ein menschliches Team übergibt, eine Belastung. Der praktische Schritt besteht darin, den bereits vorhandenen Scanner mit einer Remediation-Engine zu verbinden, die automatisch auf seine Erkenntnisse reagieren kann. Eine Plattform für autonomes Endpoint-Management (AEM) mit ringbasierter Bereitstellung und Rollback sowie Schwachstelleninformationen für einen risikobasierten Kontext ermöglicht effiziente Entscheidungen zur Behebung, sodass die Liste schrumpft, ohne dass Menschen jede einzelne Entscheidung treffen müssen.
„Wir steuern Genehmigungen über unser Ticketsystem“
Wo wir gerade davon sprechen, dass Menschen Entscheidungen treffen müssen … Lange, lineare Genehmigungsprozesse werden die Behebung erheblich verlangsamen. Wann mussten Sie zuletzt entscheiden, ob Sie das neueste Betriebssystem- oder Browser-Update bereitstellen?
Organisationen wissen bereits, dass sie diese Updates bereitstellen werden. Oft ist der Genehmigungsprozess auf komplexe interne Politik und eine fehlende Abstimmung bei den Sicherheitszielen zurückzuführen. Das Ergebnis? Ein sehr linearer Prozess, der den zuvor erwähnten Schwachstellenscanner erfordert, einen Analysten, der genehmigt, was ohnehin erledigt werden muss, sowie Tickets, die zur Genehmigung an die Verantwortlichen der Geschäftsbereiche gehen und in deren Postfächern auf eine Freigabe warten. Letztlich wird wertvolle Zeit mit einer Entscheidung verschwendet, die im Grunde bereits eindeutig war und gar nicht hätte getroffen werden müssen.
Der Wandel des Marktes hin zu Exposure Management geht diesen Prozess ganz anders an: Im Mittelpunkt stehen die Definition der Risikobereitschaft einer Organisation und die Überwachung ihrer Risikoposition. Wenn das nächste Windows-Update erscheint, wissen Sie bereits, dass Sie es bereitstellen werden, nach welchem Zeitplan Sie es ausrollen und anhand welcher SLA- und Compliance-Kennzahlen Sie den Erfolg messen. Was Sie wirklich wissen wollen, ist:
1. Muss ich schneller vorgehen, weil das Update bekannte ausgenutzte Schwachstellen behebt?
Oder
2. Beeinträchtigt das Update den Betrieb, sodass wir langsamer vorgehen müssen? (Gut, dass die Plattform für autonomes Endpoint-Management eine Ring-Bereitstellung mit Rollback umfasst.)
„Wir haben Intune“
Microsoft Intune hat hier zwei relevante Einschränkungen.
Erstens verwaltet es nur Geräte, die darin registriert sind. Nicht registrierte und nicht verwaltete Endpoints – Server, Laptops von Auftragnehmern, Schatten-IT und vernachlässigte Edge-Geräte – liegen vollständig außerhalb seiner Sichtbarkeit. In Zeiten eines erhöhten Schwachstellenaufkommens vervielfachen sich diese blinden Flecken schneller, als Teams sie manuell bewältigen können.
Zweitens vereinfacht Intune zwar die Bereitstellung und Aktualisierung von Anwendungen, doch seine Abdeckung von Drittanbieteranwendungen und die Tiefe der Priorisierung sind geringer, als die meisten Administratoren erkennen. Intune kann Ihnen sagen, was veraltet ist, aber nicht was Ihre Angriffsfläche tatsächlich vergrößert ––was Teams dazu zwingt, alles reaktiv zu patchen oder bei knapper Zeit auf Grundlage von Vermutungen vorzugehen.
Die meisten Unternehmensumgebungen bestehen nicht ausschließlich aus Windows-Systemen, sind nicht vollständig registriert und verwenden keinen kleinen, homogenen App-Stack. Wenn die Zahl der Schwachstellenmeldungen sprunghaft ansteigt, entstehen durch die Weiterleitung des Patchings Lücken, und daraus wird ein systemisches Risiko.
Behalten Sie Intune. Kombinieren Sie es mit einer Erkennungs- und Remediation-Schicht, die die von Intune nicht sichtbaren Assets findet, die wichtigsten Schwachstellen priorisiert und Patches zuverlässig für die Anwendungen einspielt, die Intune nicht abdeckt.
Was Sie dagegen tun können
Automatisierung ist das Betriebsmodell. Sie muss in den Workflow integriert sein.
Praktiker kennen dieses Prinzip schon seit einiger Zeit. Es zeigt sich an drei Stellen:
- Kontinuierliche Triage. Bekannte ausgenutzte Schwachstellen können – insbesondere in weniger sicheren Bereichen der Organisation wie Endbenutzersystemen – einem Zero-Day-Reaktionspfad folgen. Darüber hinaus sollten Sie bestimmte Anwendungen wie Browser und Telekommunikations-Apps festlegen, die nach einem priorisierten Pfad aktualisiert werden und wöchentlich oder sogar täglich überprüft werden. Alles andere kann warten, bis das reguläre Wartungsfenster ansteht.
- Ringbasierte Bereitstellung mit automatisiertem Rollback. Test-Ring, Early-Adopter-Ring, breite Produktionsumgebung, geschäftskritische Systeme. Die Abfolge ist unspektakulär und funktioniert bei den meisten Wartungsarbeiten. Geändert hat sich, dass bestimmte Updates im Gegensatz zum Warten auf die monatliche Wartung in das Zeitfenster für Exploits passen müssen. Der Test-Ring muss automatisiert und instrumentiert sein – eine Checkliste für Menschen kann nicht so schnell reagieren.
- Verifikation im geschlossenen Regelkreis. Der Patch gilt erst als bereitgestellt, wenn seine Installation auf dem Endpoint verifiziert wurde, und die CVE gilt erst als geschlossen, wenn ein erneuter Scan dies bestätigt. Die meisten Teams überspringen diesen Schritt – deshalb wird der Nachweis der Compliance in der Woche vor dem Audit zum Notfall. Aus diesem Grund haben wir diese Woche kontinuierliche Compliance in unserer Plattform eingeführt: Compliance-Nachweise werden beim Ausrollen von Patches kontinuierlich und automatisch erstellt, während die Automatisierung die Priorisierungsentscheidungen übernimmt, für die den meisten Teams die Kapazität fehlt.
Mozillas 271 Firefox-Schwachstellen sind ein Vorgeschmack. Jeder große Softwareanbieter unter dem Glasswing-Dach wird bald damit beginnen, mehr Schwachstellen in beschleunigtem Tempo zu beheben, und Angreifer mit derselben Art von Fähigkeit werden genau nach diesen Lücken suchen, sobald sie Zugriff auf ein entsprechendes Modell erhalten. Das daraus entstehende KI-Wettrüsten wird sich direkt auf die Anzahl und Häufigkeit der Updates auswirken, die Organisationen in beschleunigtem Tempo beheben müssen. Automatisierung hält ein Programm am Laufen. Teams, die weiterhin ausschließlich monatlich patchen, steht eine schwierige Zeit bevor.
Wenn Sie ein IT- oder Sicherheitsprogramm betreiben, lohnt sich die Selbstprüfung jetzt. Nehmen Sie den letzten kritischen Patch, den Sie ausgerollt haben. Noch besser: Wenn an einem Freitag ein Zero-Day veröffentlicht würde, könnten Sie ihn bis Montag beheben? Messen Sie die Zeit von der Veröffentlichung der CVE bis zur verifizierten Installation auf dem letzten Endpoint. Wird diese Zahl in Wochen gemessen, wird die Patch-Apokalypse Sie finden.
Häufig gestellte Fragen
Was ist die „Patch-Apokalypse“?
Die Patch-Apokalypse bezeichnet den raschen Anstieg öffentlich offengelegter Schwachstellen mit verfügbaren Patches, der durch die KI-beschleunigte Entdeckung von Schwachstellen vorangetrieben wird. Umfang und Geschwindigkeit der Fehlerbehebungen beginnen, die Möglichkeiten der meisten IT- und Sicherheitsteams zu übersteigen, sie mit herkömmlichen, von Menschen gesteuerten Workflows angemessen zu beheben.
Welche Lösungen können bei der „Patch-Apokalypse“ helfen?
- Eine Plattform für autonomes Endpoint-Management (AEM) mit ringbasierter Bereitstellung und Rollback sowie Schwachstelleninformationen kann einen risikobasierten Kontext für effiziente Entscheidungen zur Behebung liefern.
- Durch die Einführung eines risikobasierten Patch-Management-Ansatzes werden reale Bedrohungskontexte einbezogen, um den Fokus auf aktiv ausgenutzte Schwachstellen zu richten. Der Ansatz geht über herkömmliche Schweregradbewertungen der Anbieter und CVSS-Scores hinaus, um Schwachstellen anhand ihres tatsächlichen Risikos für eine Organisation zu identifizieren und zu priorisieren.
Welches Risiko besteht, wenn man sich nicht anpasst?
KI-Modelle können Schwachstellen in einem Umfang und mit einer Geschwindigkeit identifizieren, mit denen Menschen nicht mithalten können. Sobald Angreifer Zugriff auf ähnliche KI-Modellfähigkeiten erhalten, werden sie neu offengelegte Schwachstellen schneller ins Visier nehmen. Organisationen, die auf manuelle, fragmentierte Patchprozesse setzen, werden einer zunehmenden Gefährdung ausgesetzt sein – nicht weil keine Patches existieren, sondern weil sie diese nicht schnell genug bereitstellen können.
Lösen die alleinige Nutzung eines Schwachstellenscanners die Herausforderungen beim Patchen?
Nein. Schwachstellenscanner sind für die Erkennung unerlässlich, stellen aber keine Patches bereit, verifizieren keine Installationen, verwalten keine Rollbacks und schließen den Regelkreis nicht. Bei einer hohen Zahl von CVEs können Scanner, die lange Listen kritischer Schwachstellen erzeugen, ohne dass dahinter Automatisierung steht, die Behebung tatsächlich verlangsamen.
Warum sind ticketbasierte Genehmigungsprozesse inzwischen ein Risiko?
Lineare Genehmigungs-Workflows wurden für langsamere Patchzyklen entwickelt und werden den heutigen Realitäten nicht gerecht. Wenn Teams bereits wissen, dass Updates bereitgestellt werden, sorgen zusätzliche Genehmigungen für Verzögerungen, ohne das Risiko zu verringern. In einer sich schnell verändernden Bedrohungslage ist Zeit oft der begrenzende Faktor.





