Zusammenfassung
- KI-Modelle wie Anthropics Claude Mythos decken Schwachstellen mit hohem Schweregrad in großen Betriebssystemen und Browsern auf, verkürzen Exploit-Fenster und überfordern traditionelle, manuelle Patching-Programme.
- In großem Maßstab brechen veraltete Patching-Workflows zusammen. Wer sich allein auf Schwachstellen-Scanner, lineare ticketbasierte Freigaben oder Endpoint-Tools mit begrenzter Sichtbarkeit verlässt, erzeugt Verzögerungen, blinde Flecken und eine wachsende Exposure, wenn CVE-Volumen und -Taktung sprunghaft steigen.
- Kontinuierliche Triage, risikobasierte Priorisierung, ringbasierte Bereitstellung mit Rollback und Closed-Loop-Verifizierung sind der einzige Weg, wie IT- und Sicherheitsteams Schritt halten können, wenn Angreifer und Verteidiger gleichermaßen KI nutzen, um schneller zu werden.
Am 7. April gab Anthropic bekannt, dass sein Modell Claude Mythos Preview autonom Tausende Zero-Day-Schwachstellen mit hohem und kritischem Schweregrad in allen großen Betriebssystemen und allen großen Webbrowsern identifiziert hatte. Über 99 % davon waren am Tag der Offenlegung ungepatcht.
Zwei Wochen später, am 21. April, erklärte Mozilla, dass es dasselbe Modell genutzt habe, um 271 Schwachstellen im neuesten Firefox-Release zu finden und zu patchen. Mozillas eigene Einschätzung: „Bisher haben wir keine Kategorie oder Komplexität von Schwachstellen gefunden, die Menschen finden können und dieses Modell nicht.“
271 ist die erste Welle. Chrome, Edge, Windows, macOS, Linux, FreeBSD — die 17 Jahre alte Schwachstelle zur Remote-Code-Ausführung in FreeBSD, die Anthropics Red Team offengelegt hat (CVE-2026-4747), ist ein frühes Beispiel dafür, was bevorsteht. Jeder Anbieter unter dem Dach von Anthropics Project Glasswing ist in der Lage, Fixes in einem Tempo bereitzustellen, das die Branche so noch nicht gesehen hat. All diese Fixes werden zu öffentlichen CVEs mit verfügbaren Patches und landen damit am selben Ort: in Ihrer Umgebung.
Auch die Geschichte der Eindämmung weist Risse auf. Am 21. April berichtete Bloomberg, dass eine mit Discord verbundene Gruppe über die Umgebung eines Drittanbieters unbefugten Zugriff auf Mythos erlangt hatte. Anthropic gibt an, dass die Aktivität nicht über diesen Anbieter hinausging. Unabhängig davon, ob vergleichbare Fähigkeiten bereits in den Händen von Angreifern sind, ist der defensive Handlungsspielraum kürzer, als die Ankündigung vom 7. April vermuten ließ.
Mythos kam in eine Welt, die sich bereits in diese Richtung entwickelte. Der Global Threat Report 2026 von CrowdStrike dokumentierte für 2025 einen Anstieg KI-gestützter Angriffe um 89 % gegenüber dem Vorjahr. Diese Entwicklung begann schon vor Mythos.
Nennen wir es eine Patch-Apokalypse. Gemeint ist die ganz praktische operative Variante, bei der Volumen und Taktung öffentlicher CVEs mit verfügbaren Patches dabei sind, die heutige Arbeitsweise der meisten IT- und Sicherheitsteams zu überholen.
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 grundlegende Änderung im Betrieb der National Vulnerability Database (NVD) an. NIST wird nicht mehr für alle eingereichten Schwachstellen eine detaillierte Anreicherung bereitstellen, sondern nur noch für Schwachstellen, die Hochrisikokriterien erfüllen, beispielsweise solche im CISA-Katalog Known Exploited Vulnerabilities oder solche, die kritische Regierungssoftware betreffen. NIST wird sich künftig auf CVE Numbering Authorities (CNAs) wie Ivanti stützen, statt eigene unabhängige Bewertungen vorzunehmen.
Seit der Ankündigung höre ich von Kunden und Fachkollegen drei Varianten derselben Reaktion. Alle drei sind Varianten eines Programms, das für eine langsamere Welt konzipiert wurde.
„Wir haben einen Schwachstellen-Scanner“
Qualys, Rapid7 und Tenable leisten bei der Schwachstellenerkennung gute Arbeit. Scanner finden, markieren, bewerten und listen auf. Bereitstellung, Verifizierung, Neustart-Handling und Rollback liegen außerhalb ihres Leistungsumfangs. Diese Arbeit muss weiterhin irgendwo erledigt werden. In den meisten Programmen geschieht das in einem separaten Tool, mit einem separaten Team und in einem separaten Rhythmus.
Da das Exploit-Fenster inzwischen in Stunden gemessen wird und die Glasswing-Warteschlange den Rückstand nahezu verdoppeln dürfte, wird ein Scanner, der 587 kritische Schwachstellen ausgibt und die Liste an ein menschliches Team übergibt, zum Risiko. Der pragmatische 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 bietet den risikobasierten Kontext für effiziente Remediation-Entscheidungen, damit die Liste schrumpft, ohne dass Menschen jede einzelne Entscheidung treffen müssen.
„Wir steuern Freigaben über unser Ticketsystem“
Apropos Entscheidungen durch Menschen ... Lange, lineare Freigabeprozesse werden den Remediation-Prozess deutlich verlangsamen. Wann mussten Sie zuletzt entscheiden, ob Sie das neueste Betriebssystem- oder Browser-Update bereitstellen?
Unternehmen wissen bereits, dass sie diese Updates bereitstellen werden. Häufig ist der Freigabeprozess auf komplexe interne Politik und fehlende Abstimmung über Sicherheitsziele zurückzuführen. Das Ergebnis? Ein sehr linearer Prozess, der den zuvor erwähnten Schwachstellen-Scanner erfordert, einen Analysten, der das genehmigt, von dem Sie bereits wissen, dass es getan werden muss, Tickets, die zur Freigabe an Business Owner gehen und in Posteingängen auf Freigabe warten, und letztlich wertvolle Zeit, die für eine Entscheidung verloren geht, die im Grunde bereits klar war und nicht hätte getroffen werden müssen.
Der Wandel im Markt hin zu Exposure Management geht diesen Prozess ganz anders an, indem er den Fokus darauf legt, die Risikobereitschaft eines Unternehmens zu definieren und dessen Risikolage zu überwachen. Wenn das nächste Windows-Betriebssystem-Update erscheint, wissen Sie bereits, dass Sie es bereitstellen werden, nach welchem Zeitplan dies geschieht und anhand welcher SLA- und Compliance-Kennzahlen Sie den Erfolg messen. Was Sie wirklich wissen möchten, ist:
1. Müssen wir schneller handeln, weil das Update bekannte, aktiv ausgenutzte Schwachstellen enthält?
Oder
2. Beeinträchtigt das Update den Betrieb und müssen wir das Tempo drosseln (gut, dass die Autonomous-Endpoint-Management-Plattform Ringbereitstellung mit Rollback umfasst)?
„Wir haben Intune“
Microsoft Intune hat hier zwei relevante Einschränkungen im Umfang.
Erstens verwaltet es nur Geräte, die in Intune registriert sind. Nicht registrierte und nicht verwaltete Endpoints — Server, Laptops von Auftragnehmern, Schatten-IT, vernachlässigte Edge-Geräte — liegen vollständig außerhalb seiner Sichtbarkeit. In Phasen steigenden Schwachstellenvolumens vermehren sich diese blinden Flecken schneller, als Teams sie manuell bewältigen können.
Zweitens vereinfacht Intune zwar die Bereitstellung und Aktualisierung von Anwendungen, doch die Abdeckung von Drittanbieteranwendungen und die Tiefe der Priorisierung sind begrenzter, als den meisten Administratoren bewusst ist. Intune kann Ihnen sagen, was veraltet ist, aber nicht, was Ihre Exposure tatsächlich erhöht — und zwingt Teams damit, alles reaktiv zu patchen oder auf Vermutungen zu setzen, wenn die Zeit knapp ist.
Die meisten Unternehmensumgebungen bestehen nicht ausschließlich aus Windows, sind nicht vollständig registriert und nutzen keinen kleinen, homogenen Anwendungsstack. Wenn Schwachstellenmeldungen sprunghaft zunehmen, lässt das Weiterleiten von Patching-Aufgaben Lücken entstehen und wird zu einem systemischen Risiko.
Behalten Sie Intune. Kombinieren Sie es mit einer Erkennungs- und Remediation-Ebene, die die Assets findet, die Intune nicht sehen kann, die wichtigsten Schwachstellen priorisiert und Patches zuverlässig für die Anwendungen anwendet, 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, aktiv ausgenutzte Schwachstellen können einem Zero-Day-Reaktionspfad folgen, insbesondere in weniger sicheren Bereichen der Organisation wie Endbenutzersystemen. Darüber hinaus sollten bestimmte Anwendungen wie Browser und Telekommunikations-Apps definiert und festgelegt werden, die auf einem priorisierten Pfad aktualisiert werden, der wöchentlich oder sogar täglich überprüft wird. Alles andere kann bis zum regulären Wartungsfenster warten.
- Ringbasierte Bereitstellung mit automatisiertem Rollback. Testring, Early-Adopter-Ring, breite Produktion, geschäftskritisch. Die Abfolge ist unspektakulär, und sie funktioniert für die meisten Wartungsarbeiten. Geändert hat sich, dass bestimmte Updates komprimiert werden müssen, um in das Exploit-Fenster zu passen, statt auf die monatliche Wartung zu warten. Der Testring muss automatisiert und instrumentiert sein — eine menschliche Checkliste kann nicht so schnell mithalten.
- Closed-Loop-Verifizierung. Der Patch gilt erst dann als bereitgestellt, wenn seine Installation auf dem Endpoint verifiziert wurde, und die CVE gilt erst dann als geschlossen, wenn ein erneuter Scan dies bestätigt. Die meisten Teams überspringen diesen Schritt. Deshalb wird der Compliance-Nachweis in der Woche vor dem Audit oft zur Feuerwehrübung. Aus diesem Grund haben wir diese Woche kontinuierliche Compliance in unserer Plattform veröffentlicht — damit Compliance-Nachweise kontinuierlich und automatisch entstehen, während Patches bereitgestellt werden, und die Automatisierung die Priorisierungsentscheidungen übernimmt, für die den meisten Teams die Kapazität fehlt.
Mozillas 271 Firefox-Schwachstellen sind ein Ausblick. Jeder große Softwareanbieter unter Glasswing wird beginnen, mehr Schwachstellen in beschleunigtem Tempo zu beheben, und Angreifer mit derselben Art von Fähigkeiten werden genau nach diesen Öffnungen suchen, sobald sie Zugriff auf ein entsprechendes Modell erhalten. Das daraus entstehende KI-Wettrüsten wird direkte Auswirkungen auf Anzahl und Häufigkeit der Updates haben, die Unternehmen in beschleunigtem Tempo beheben müssen. Automatisierung ist das, was ein Programm dadurch trägt. Teams, die weiterhin ausschließlich monatlich patchen, stehen vor einer schwierigen Phase.
Wenn Sie ein IT- oder Sicherheitsprogramm verantworten, lohnt sich die Selbstbewertung 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 CVE-Veröffentlichung bis zur verifizierten Installation auf dem letzten Endpoint. Wenn diese Zahl in Wochen gemessen wird, wird die Patch-Apokalypse Sie treffen.
FAQs
Was ist die „Patch-Apokalypse“?
Die Patch-Apokalypse bezeichnet den rasanten Anstieg öffentlich offengelegter Schwachstellen mit verfügbaren Patches, angetrieben durch KI-beschleunigte Schwachstellenerkennung. Umfang und Geschwindigkeit der Fixes beginnen, die Fähigkeit der meisten IT- und Sicherheitsteams zu überholen, diese mit traditionellen, vom Menschen gesteuerten Workflows angemessen zu beheben.
Welche Lösungen können bei der Bewältigung der „Patch-Apokalypse“ helfen?
- Eine Plattform für autonomes Endpoint-Management (AEM) mit ringbasierter Bereitstellung und Rollback sowie Schwachstelleninformationen kann risikobasierten Kontext für effiziente Remediation-Entscheidungen liefern.
- Durch die Einführung eines risikobasierten Patch-Management-Ansatzes wird realer Bedrohungskontext einbezogen, um den Fokus auf Schwachstellen zu legen, die aktiv ausgenutzt werden. Der Ansatz geht über traditionelle Schweregradbewertungen von Anbietern und CVSS-Scores hinaus, um Schwachstellen auf Basis ihres tatsächlichen Risikos für ein Unternehmen 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, die Menschen nicht erreichen können. Wenn Angreifer Zugang zu ähnlichen KI-Modellfähigkeiten erhalten, werden sie neu offengelegte Schwachstellen schneller ins Visier nehmen. Unternehmen, die auf manuelle, fragmentierte Patching-Prozesse setzen, werden eine zunehmende Exposure erleben – nicht, weil es keine Patches gibt, sondern weil sie diese nicht schnell genug bereitstellen können.
Löst ein Schwachstellen-Scanner allein die Herausforderungen beim Patching?
Nein. Schwachstellen-Scanner sind für die Erkennung unverzichtbar, aber sie stellen keine Patches bereit, verifizieren keine Installationen, verwalten keine Rollbacks und schließen den Kreislauf nicht. Bei hohen CVE-Volumina können Scanner, die lange kritische Listen erzeugen, ohne dass dahinter Automatisierung steht, die Remediation sogar verlangsamen.
Warum sind ticketbasierte Freigabeprozesse jetzt ein Risiko?
Lineare Freigabe-Workflows wurden für langsamere Patch-Zyklen entwickelt und werden den heutigen Realitäten nicht gerecht. Wenn Teams bereits wissen, dass Updates bereitgestellt werden, verursachen zusätzliche Freigaben Verzögerungen, ohne das Risiko zu reduzieren. In einer dynamischen Bedrohungsumgebung ist Zeit oft der begrenzende Faktor.
