Die unangenehme Nachricht an Sicherheitsverantwortliche lautet nicht, dass ein KI-Modell Sicherheitslücken ausnutzen kann. Das war bereits absehbar. Die Nachricht ist nüchterner und für Unternehmen deutlich härter: Der organisatorische Puffer zwischen Schwachstelle, Bewertung, Ticket, Freigabe, Wartungsfenster und Patch schrumpft schneller, als viele Sicherheitsprozesse umgebaut werden.
Claude Mythos ist deshalb weniger ein einzelnes Anthropic-Thema als ein Stresstest für die Annahmen hinter Enterprise-Patching. Viele Firmen behandeln Schwachstellenmanagement noch immer wie ein geregeltes Verwaltungsverfahren. Eine CVE wird veröffentlicht, ein Score wird zugewiesen, ein Team priorisiert, ein anderes testet, ein drittes rollt aus. Dazwischen liegen Abhängigkeiten, Change Boards, Herstellerfreigaben, Legacy-Systeme und Wochenenden. Dieses Modell funktionierte, solange Angreifer ähnlich viel Zeit brauchten wie Verteidiger. Genau diese Symmetrie bricht.
Der alte Sicherheitsabstand war nie technisch
Ein Hinweis darauf kam schon 2024. Forschende der University of Illinois zeigten damals, dass GPT-4 mit einer CVE-Beschreibung 87 Prozent eines kuratierten Datensatzes von 15 sogenannten One-Day-Schwachstellen autonom ausnutzen konnte. Ohne diese Beschreibung lag die Quote bei 7 Prozent. Für die Industrie war das ein unbequemer, aber noch beherrschbarer Befund: KI konnte bekannte Schwachstellen operationalisieren, scheiterte aber weitgehend daran, sie selbst zu finden.
Dieser Unterschied war der eigentliche Sicherheitsabstand. Nicht weil die Systeme sicher waren, sondern weil Wissen, Kontext und Exploit-Entwicklung Zeit kosteten. Ein Advisory, ein Proof of Concept, ein Blogbeitrag oder ein Exploit-Modul veränderten das Risiko. Vorher war eine Lücke häufig ein abstrakter Eintrag in einer Datenbank. Danach wurde sie ein operatives Ziel.
Mit der Ankündigung von Anthropic am 7. April zu Claude Mythos Preview verschiebt sich diese Linie. Anthropic erklärte, das Modell habe autonom tausende Zero-Day-Schwachstellen in großen Betriebssystemen und Browsern entdeckt. Separat erreichte Mythos 83,1 Prozent im CyberGym-Benchmark zur Reproduktion von Schwachstellen. In einer Kampagne gegen OpenBSD über 1.000 Scaffold-Läufe lagen die gesamten Rechenkosten unter 20.000 US-Dollar.
Benchmarks sind keine reale Angriffslandschaft. Aber in Sicherheitsökonomie zählen Wiederholbarkeit, Kosten und Geschwindigkeit. Wenn automatisierte Systeme Schwachstellen nicht nur nachbauen, sondern in größerem Umfang suchen können, verliert die klassische Trennung zwischen Bekanntwerden und Ausnutzung an Tragfähigkeit.
Patchfenster kollidieren mit Exploit-Zeiten
Die praktischen Beispiele sind bereits eng genug, um keine theoretische Debatte daraus zu machen. Langflow CVE-2026-33017, bewertet mit CVSS 9.8, wurde 20 Stunden nach Veröffentlichung ausgenutzt, ohne dass ein öffentlicher Proof of Concept vorlag. Marimo CVE-2026-39987, CVSS 9.3, wurde nach 9 Stunden und 41 Minuten angegriffen.
Das ist eine andere Taktung als die, für die viele Unternehmen gebaut sind. Ein Patch, der erst im nächsten regulären Wartungsfenster landet, ist in solchen Fällen keine kontrollierte Verzögerung mehr, sondern ein offenes Zeitfenster für Missbrauch. Besonders problematisch wird das bei Plattformen, Entwicklungswerkzeugen, internen Automatisierungssystemen und Komponenten, die tief in Unternehmensabläufen hängen. Dort ist Patchen selten ein einzelner Knopfdruck. Es ist ein Eingriff in Abhängigkeiten.
Rapid7 nennt im Threat-Landscape-Bericht 2026 eine Medianzeit von fünf Tagen zwischen CVE-Veröffentlichung und Aufnahme in CISA KEV, die Liste bekanntermaßen ausgenutzter Schwachstellen. Diese fünf Tage sind für viele Firmen bereits schnell. Für automatisierte Ausnutzung sind sie zu lang. Google beschreibt in M-Trends 2026 zudem Fälle, in denen Ausnutzung stattfindet, bevor überhaupt ein Patch verfügbar ist.
Damit wird CISA KEV nicht wertlos. Im Gegenteil: Die Liste bleibt ein wichtiges Eskalationssignal. Aber wer erst dann reagiert, wenn eine Schwachstelle dort auftaucht, behandelt ein Warnsignal als Startschuss. In einer Umgebung, in der Exploits binnen Stunden auftauchen, ist das zu spät.
CVSS allein sortiert die falsche Warteschlange
Viele Vulnerability-Management-Programme priorisieren noch immer stark nach CVSS. Das ist verständlich, weil CVSS einfach vergleichbar wirkt. Der Score beschreibt aber vor allem theoretische Schwere. Er sagt nicht zuverlässig, ob eine Schwachstelle tatsächlich angegriffen wird, wie leicht sie sich automatisieren lässt oder ob sie in der eigenen Umgebung exponiert ist.
Der Unterschied ist operativ entscheidend. Eine CVSS-9.8-Lücke, die zwar schwer klingt, aber nicht ausgenutzt wird, kann in der Warteschlange vor einer CVSS-8.8-Lücke landen, die bereits aktiv missbraucht wird. Als Beispiel wird Docker CVE-2026-34040 genannt: niedriger als manche kritische Schwachstelle, aber mit Ausnutzungshistorie. In einem überlasteten Patchprozess ist eine solche Fehlpriorisierung kein kleiner Bewertungsfehler. Sie bindet genau die Teams, die an anderer Stelle Stunden verlieren.
Ein belastbareres Modell ist ein dreistufiger Filter: zuerst CISA KEV als Signal für bekannte Ausnutzung, dann EPSS als Wahrscheinlichkeit für künftige Ausnutzung, danach CVSS als Schweregrad. Eine Studie mit 28.377 realen Schwachstellen stützt einen solchen Entscheidungsbaum. Der Punkt ist nicht, CVSS abzuschaffen. Der Punkt ist, den Score vom alleinigen Richter zum dritten Faktor zu machen.
Das Problem liegt in der Plattformlogik
Enterprise-Patching ist selten nur ein Security-Prozess. Es ist Plattformsteuerung. Wer darf welche Komponente aktualisieren? Welche Teams besitzen welche Images, Bibliotheken, Container, Agents und Browser-Versionen? Welche Systeme hängen an nicht dokumentierten Schnittstellen? Welche Hersteller liefern Patches, aber keine belastbare Migrationslogik?
KI beschleunigt nicht nur Angriffe. Sie macht sichtbar, wo Unternehmen ihre Plattformen nie sauber operationalisiert haben. Wenn ein Team nicht weiß, welche Langflow-Instanzen erreichbar sind, hilft auch der schnellste Advisory-Prozess wenig. Wenn Marimo in Entwicklungsumgebungen läuft, aber nicht zentral inventarisiert ist, beginnt die Verzögerung vor der eigentlichen Bewertung. Wenn Betriebssysteme, Browser und interne Tools über verschiedene Eigentümer verteilt sind, entstehen Lücken nicht nur im Code, sondern in Zuständigkeiten.
Die Konsequenz ist trocken: Unternehmen brauchen kürzere Wege zwischen Erkennung und Änderung. Asset-Inventar, Exponierungsdaten, Exploit-Wahrscheinlichkeit und Patch-Automatisierung müssen näher zusammenrücken. Nicht als großes Transformationsprogramm, sondern als tägliche Betriebsfähigkeit. Eine Schwachstelle darf nicht erst durch fünf Systeme wandern, bevor jemand entscheidet, ob sie relevant ist.
Langsamkeit wird messbar
Claude Mythos liefert keine Entschuldigung für Panik. Es liefert einen Maßstab. Wenn ein Modell für unter 20.000 US-Dollar in einer Testkampagne systematisch nach Schwachstellen suchen kann, ist die Frage nach Angreiferbudgets anders zu stellen. Wenn Exploits nach 20 Stunden oder unter 10 Stunden auftauchen, ist ein Patchprozess mit mehrtägiger Reaktionszeit nicht konservativ. Er ist exponiert.
Die meisten Unternehmen werden nicht jede kritische Lücke sofort patchen können. Das ist operative Realität. Aber sie müssen wissen, welche Systeme zuerst dran sind, welche Ausnahmen wirklich vertretbar sind und welche Kompensationsmaßnahmen sofort greifen. Die alte Komfortzone bestand darin, dass Ausnutzung Zeit brauchte. Diese Zeit war nie garantiert. Jetzt wird sie knapp.
