Claude Mythos und BSI-Warnung: Wenn KI schneller findet, als Sie patchen

75 von 530. So viele der hoch oder kritisch eingestuften Schwachstellen, die Anthropic bis zum 22. Mai an Open-Source-Maintainer gemeldet hatte, waren zu diesem Zeitpunkt behoben (Anthropic, Project Glasswing: An initial update). Das sind rund 14 Prozent. Gefunden hatte das Modell in derselben Zeit 23.019 mögliche Schwachstellen in mehr als 1.000 Projekten.

Diese beiden Zahlen nebeneinander erklären, warum das BSI vier Wochen später eine Cybersicherheitswarnung herausgegeben hat, die neben den Administratoren ausdrücklich die Leitungsebene in die Pflicht nimmt. Das Finden ist billig geworden. Das Beheben nicht.

In meinem Artikel über AI-Angriffe 2025 stand die KI-gestützte Suche nach Zero-Days noch als Vermutung: Researcher wunderten sich über eine Häufung von Router- und VPN-Lücken und tippten auf KI. Ein Dreivierteljahr später gibt es dazu Herstellerzahlen, eine unabhängige staatliche Prüfung und eine deutsche Behördenwarnung. Zeit für eine Fortsetzung.

Was Anthropic im April gezeigt hat

Am 7. April 2026 hat Anthropic Project Glasswing angekündigt. Partner sind unter anderem AWS, Apple, Cisco, CrowdStrike, Google, Microsoft, die Linux Foundation und Palo Alto Networks, dazu über 40 weitere Organisationen, die kritische Software pflegen. Sie erhalten Zugang zu Claude Mythos Preview, einem Modell, das Anthropic nach eigener Aussage nicht allgemein verfügbar machen will. Anthropic stellt bis zu 100 Millionen US-Dollar an Nutzungsguthaben und 4 Millionen US-Dollar an Spenden für Open-Source-Sicherheitsorganisationen bereit.

Der technische Begleitbericht nennt Beispiele. Ein 27 Jahre alter Fehler in OpenBSD, einem Betriebssystem, dessen Entwickler Sicherheit nicht gerade als Hobby betreiben. Ein 16 Jahre alter Fehler in FFmpeg, der Bibliothek, die in fast jedem Dienst steckt, der Videos verarbeitet. Laut Bericht können auch Anthropic-Ingenieure ohne formale Security-Ausbildung das Modell abends auf die Suche schicken und morgens einen funktionierenden Exploit vorfinden.

Für Entscheider ist die Kostenangabe interessanter als jede Einzellücke. Tausend Durchläufe gegen OpenBSD kosteten laut Anthropic insgesamt unter 20.000 US-Dollar. Der eine Durchlauf, der den 27 Jahre alten Fehler fand, unter 50 Dollar. Anthropic schreibt selbst dazu, dass diese zweite Zahl nur im Rückblick Sinn ergibt, weil vorher niemand weiß, welcher Durchlauf trifft. Trotzdem: Ein Betrag, der in vielen Security-Budgets ein einzelner Posten ist, reicht jetzt für die systematische Durchsuchung eines ganzen Betriebssystems.

Sechs Wochen später ist das Patchen der Engpass

Das Update vom 22. Mai ist der eigentlich lesenswerte Text, Help Net Security hat ihn am 26. Mai zusammengefasst. Die Zahlen für den Open-Source-Teil, alle nach Angabe von Anthropic:

Dazu kommt ein Satz, den ich so von einem Hersteller nicht erwartet hätte. Mehrere Maintainer seien stark überlastet, einige hätten Anthropic gebeten, langsamer zu melden, weil sie Zeit für die Patches brauchen. Im Schnitt dauere die Behebung eines solchen Fundes zwei Wochen. Anthropics eigene Zusammenfassung: Der Fortschritt in der Softwaresicherheit sei früher dadurch begrenzt gewesen, wie schnell man Lücken findet. Jetzt begrenze ihn, wie schnell man sie prüfen, melden und beheben kann.

Auch bei den Partnern zeigt sich das Muster. Cloudflare hat laut Update 2.000 Fehler in den eigenen kritischen Systemen gefunden, 400 davon hoch oder kritisch. Mozilla hat in Firefox 150 während der Tests 271 Schwachstellen behoben. Das aktuelle Release von Palo Alto Networks enthielt über fünfmal so viele Patches wie üblich.

Dieser letzte Punkt betrifft Sie direkt. Wenn Ihre Hersteller fünfmal so viele Sicherheitsupdates liefern, muss Ihr Betrieb fünfmal so viele bewerten, testen und einspielen. Mit denselben Leuten und denselben Wartungsfenstern.

Das BSI schreibt an die Leitungsebene

Am 22. Juni 2026 hat das BSI die Warnung „Auswirkungen auf die Cybersicherheit von Organisationen durch die Entwicklung im Bereich Künstlicher Intelligenz“ veröffentlicht. Kritikalität 2 von 4, also Gelb: Maßnahmen müssen zeitnah ergriffen werden. Das Dokument nennt Claude Mythos und OpenAI GPT-5.5 namentlich, weist aber darauf hin, dass auch die günstigeren, kleineren Modelle eine Rolle spielen.

Der Kernsatz: „KI senkt Aufwand, Zeitbedarf und Einstiegshürden für offensive Cyberfähigkeiten maßgeblich.“ Angreifer profitieren von Geschwindigkeit, Skalierung und Automatisierung. Verteidiger bleiben laut BSI „an reale Betriebsgrenzen gebunden“, genannt werden Testaufwand, Freigabeprozesse, Wartungsfenster, Herstellerabhängigkeiten und knappes Personal. Die Schlussfolgerung der Behörde: Um trotzdem Schritt zu halten, „muss die Angriffsfläche grundsätzlich minimiert werden“.

Dann wird das BSI ungewohnt konkret. Das Patchmanagement müsse in die Lage versetzt werden, Schwachstellen „innerhalb kürzester Zeit (Minuten bis maximal wenige Stunden)“ zu sichten, zu bewerten und bei Bedarf zu patchen. Wörtlich: „wenige Tage sind dabei keine angemessene Reaktionsgeschwindigkeit“. Aus veröffentlichten Patches lasse sich mit KI innerhalb von Minuten bis Stunden ableiten, wie ein Exploit aussehen muss, während Betreiber oft Tage bis Wochen für das Ausrollen brauchen. Zur Einordnung zitiert das BSI den M-Trends-Bericht 2026 von Mandiant: Die mediane Zeit bis zur Ausnutzung einer Schwachstelle liegt in den dort untersuchten Vorfällen bei minus sieben Tagen. Ausgenutzt wurde im Mittel also eine Woche, bevor es einen Patch gab.

Ich hatte im Artikel vom Herbst Patch-Zyklen unter 72 Stunden für kritische CVEs empfohlen und fand das damals ambitioniert. Das BSI hält das inzwischen für zu langsam, zumindest für exponierte Systeme.

Ein zweiter Punkt der Warnung wird in vielen Häusern Arbeit machen. Der CVSS Base Score allein reicht dem BSI nicht mehr, weil KI-Modelle mehrere mittelschwere Lücken zu einem vollständigen Angriffspfad verketten können. Wer heute nach der Regel „alles ab 9,0 sofort, der Rest im nächsten Quartal“ arbeitet, priorisiert an der Bedrohung vorbei.

Wo ich den Herstellerangaben nicht blind folge

Anthropic ist Partei. Das Unternehmen verkauft Modelle, und eine Ankündigung mit elf großen Partnernamen ist auch Marketing. Ich halte die Zahlen trotzdem für brauchbar, solange man ihre Grenzen mitliest.

Die 23.019 und die 6.202 sind Einschätzungen des Modells, keine bestätigten Lücken. Geprüft wurden 1.752, und von denen wurden 62,4 Prozent tatsächlich als hoch oder kritisch bestätigt. In gut einem Drittel der geprüften Fälle lag die Einstufung des Modells also zu hoch, oder der Fund war keiner. Die Prüfung lief über sechs externe Sicherheitsfirmen und in einigen Fällen über Anthropic selbst. Auswertung und Veröffentlichung liegen aber beim Hersteller. Und weil laut Aprilbericht über 99 Prozent der Funde noch nicht gepatcht waren, kann bisher niemand außerhalb des Programms die Details nachvollziehen.

Die beste unabhängige Quelle, die ich kenne, ist das britische AI Security Institute. Es hat Mythos Preview am 13. April bewertet. Ergebnis: Das Modell ist das erste, das eine simulierte Unternehmensnetz-Übernahme in 32 Schritten vollständig geschafft hat, in 3 von 10 Versuchen. Die Einschränkung steht gleich daneben. Die Testumgebungen hatten keine aktiven Verteidiger, keine Sicherheitswerkzeuge und keine Nachteile für Aktionen, die in der Realität einen Alarm auslösen würden. AISI spricht von kleinen, schwach verteidigten, verwundbaren Systemen.

Das ist für mich die nüchterne Lesart. Ein Netz mit Segmentierung, Monitoring und halbwegs aktuellem Patchstand ist nach wie vor ein anderes Ziel als eine Laborumgebung. Das BSI sagt es ähnlich: Die bisherigen Sicherheitsansätze werden nicht hinfällig, sie müssen schneller werden. Und es hält sogar für möglich, dass KI-Suche langfristig dazu führt, dass in neuen Releases kaum noch klassische Schwachstellen stecken. Bis dahin liegt eine unangenehme Übergangsphase vor uns, in der sehr viel alter Code gleichzeitig durchleuchtet wird.

Was ich nicht weiß: wie schnell vergleichbare Fähigkeiten bei Angreifern ankommen. Mythos ist nicht frei verfügbar. Aber das BSI rechnet offenkundig nicht damit, dass das so bleibt, und ich würde darauf auch keine Planung bauen.

Vier Dinge ändern sich für Verteidiger

Erstens wird das Alter von Code zum Risiko. Lücken, die 16 oder 27 Jahre lang niemand gefunden hat, werden jetzt gefunden. Die Annahme „läuft seit Jahren stabil, da ist nichts“ war schon immer bequem und ist jetzt falsch. Das trifft Altsysteme besonders, für die es keinen Hersteller-Support mehr gibt. Dort wird gefunden, aber nicht mehr behoben.

Zweitens verlagert sich der Engpass zu Ihnen. Hersteller liefern mehr Patches, Open-Source-Projekte kommen mit dem Beheben nicht nach, und das BSI rechnet ausdrücklich mit mehr bekannten Lücken, für die es vorübergehend keinen Patch gibt. Für diese Phase brauchen Sie Alternativen zum Patchen: Dienst abschalten, Zugriff einschränken, System vom Internet trennen. Das BSI empfiehlt Letzteres für ausgewählte exponierte Systeme ausdrücklich.

Drittens wird Exposition zur wichtigsten Stellschraube. Jedes aus dem Internet erreichbare System ist laut BSI für automatisierte Angriffe „interessant“. In Projekten sehe ich regelmäßig Admin-Oberflächen, Testsysteme und vergessene VPN-Zugänge, die niemand mehr auf dem Schirm hatte. Was nicht erreichbar ist, muss nicht innerhalb von Stunden gepatcht werden.

Viertens brauchen Sie ein Inventar, das Fragen in Minuten beantwortet. Wenn eine Lücke in einer Bibliothek bekannt wird, müssen Sie wissen, in welchen Ihrer Anwendungen sie steckt. Das leistet eine SBOM, wie ich sie im Artikel zum Cyber Resilience Act in der Softwareentwicklung beschrieben habe. Das BSI ergänzt automatisierte Advisories im CSAF-Format, damit niemand mehr Herstellermeldungen von Hand sichten muss.

Was Geschäftsführung und CISO entscheiden müssen

Das BSI schreibt, die Maßnahmen könnten nur gelingen, wenn die Leitungsebene Budget und eine verantwortliche Stelle bereitstellt. Ich sehe fünf Entscheidungen, in dieser Reihenfolge.

Zur Kennzahl: Ich würde zwei Werte berichten lassen. Die Zeit von der Herstellermeldung bis zum eingespielten Patch auf exponierten Systemen, als Median und als schlechtester Fall. Und die Zahl der aus dem Internet erreichbaren Dienste. Beide gehören in denselben Bericht wie Umsatz und Liquidität. Wenn die zweite Zahl sinkt, wird die erste weniger dringend.

Zur Notfallregel: Das BSI weist darauf hin, dass viele US-Hersteller ihre Advisories am späten Nachmittag oder Abend deutscher Zeit veröffentlichen. Wenn dann erst drei Personen erreicht werden müssen, bevor jemand einen Dienst abschalten darf, sind die geforderten Stunden vorbei. Diese Befugnis zu regeln kostet fast nichts und ist trotzdem in den wenigsten Häusern geregelt.

Zu den Lieferanten: Fragen Sie konkret. Wie lange hat es bei den letzten drei kritischen Lücken vom Bekanntwerden bis zum Patch gedauert? Liefern Sie eine maschinenlesbare SBOM? Setzen Sie selbst KI-gestützte Codeprüfung vor dem Release ein? Das BSI empfiehlt Herstellern genau das. Ein Lieferant, der auf diese Fragen nur mit seinem ISO-Zertifikat antwortet, hat sie nicht verstanden.

Vollautomatisches Patchen ist übrigens nicht die einfache Antwort. Das BSI warnt selbst davor, Updates ungeprüft auszurollen, weil ein fehlerhafter Patch den Betrieb genauso lahmlegen kann wie ein Angriff. Realistisch ist eine Trennung: Perimetersysteme schnell und weitgehend automatisch, mit Backup und Rückfallplan. Interne Kernsysteme mit Test, dafür gut segmentiert.

Und die eigene Seite: Wenn Sie selbst Software entwickeln, gehört KI-gestützte Codeprüfung in die Pipeline, bevor andere Ihren Code damit lesen. Wie das in einen Entwicklungsprozess passt, steht im Artikel zum Secure SDLC.

Der Schritt für diese Woche

Lassen Sie sich eine Liste aller Systeme geben, die aus dem Internet erreichbar sind, mit Verantwortlichem und Datum des letzten Patches. Nicht aus der Dokumentation, sondern aus einem Scan von außen. Wenn diese Liste bis Freitag nicht vorliegt, kennen Sie Ihre erste Baustelle. Wenn sie vorliegt, streichen Sie alles, was dort nicht stehen muss.

Weiterführend

• AI-Angriffe 2025: der Vorgängerartikel mit den fünf Angriffsvektoren
• CRA und Softwareentwicklung: SBOM und Schwachstellen-Management aus Herstellersicht
• KI Security Framework: Inventar und Priorisierung als strukturierter Prozess
• Secure SDLC: Sicherheitsprüfungen in der Entwicklungspipeline

Quellen

• Anthropic, „Project Glasswing: Securing critical software for the AI era“, 07.04.2026, https://www.anthropic.com/glasswing
• Anthropic, „Claude Mythos Preview“ (technischer Bericht zu den Cyberfähigkeiten), 07.04.2026, https://www.anthropic.com/research/mythos-preview
• Anthropic, „Project Glasswing: An initial update“, 22.05.2026, https://www.anthropic.com/research/glasswing-initial-update
• The Hacker News, Bericht zu Claude Mythos und Project Glasswing, 08.04.2026, https://thehackernews.com/2026/04/anthropics-claude-mythos-finds.html
• Help Net Security, Bericht zum Glasswing-Update, 26.05.2026, https://www.helpnetsecurity.com/2026/05/26/anthropic-project-glasswing-update/
• AI Security Institute (UK), „Our evaluation of Claude Mythos Preview’s cyber capabilities“, 13.04.2026, https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities
• BSI, „Auswirkungen auf die Cybersicherheit von Organisationen durch die Entwicklung im Bereich Künstlicher Intelligenz“, BITS-B Nr. 2026-262788-1032, Version 1.0, 22.06.2026, https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2026/2026-262788-1032.pdf