Cybersicherheit
Teknosfera-Redaktion
Cybersicherheit

Anthropics Exploit-Ketten: Nicht das Modell ist die Geschichte, sondern die Patch-Lücke

Ein unveröffentlichtes Claude-Modell verkettete Fehler zu funktionierenden Exploits für Chrome, Safari und Linux. Entscheidend ist, wer diese Fähigkeit zuerst hat und ob Hersteller mithalten können.

Veröffentlicht
2. November 2026
Lesezeit
4 min
Kategorien
Cybersicherheit

Foto: Software: Anthropic PBC Screenshot: VulcanSphere / Wikimedia Commons (Public domain)

Ist es beängstigend, dass eine KI einen funktionierenden Exploit für Chrome, Safari und Linux schreiben kann? Weniger als die unspektakuläre Frage dahinter: Wer hat den nächsten in der Hand, bevor der Patch erscheint?

Das ist passiert. Am 27. Oktober veröffentlichte das Frontier Red Team von Anthropic einen Forschungsbeitrag. Darin heißt es, ein unveröffentlichtes internes Forschungsmodell habe in den vergangenen Monaten kritische Schwachstellen in Browsern und Betriebssystemen gefunden. Laut The Hacker News verkettete das Modell Fehler zu funktionierenden Proof-of-Concept-Exploits für Chrome, Safari, Android, Windows und Linux. Diese Exploits entstanden nach entsprechender Aufforderung im Labor, in echten Angriffen wurden sie nicht beobachtet, und jede Schwachstelle wurde zuerst dem Hersteller gemeldet, sodass alle bereits gepatcht sind.

Ein Fall zeigt die Beschaffenheit des Ganzen. Der Linux-Fehler CVE-2026-98432 ist ein Use-after-free im TCP-Handshake, der seit Linux 4.4 existiert. Frandroid berichtet, dass das Modell nach einem ersten Prompt eines Forschers einen Remote-Root-Exploit schrieb: 48 Minuten, um eine Kernel-Adresse auszulesen, fünf weitere, um die Kontrolle zu übernehmen.

Die Fähigkeit ist die Schlagzeile, aber nicht die Geschichte

Dass Modelle Fehler finden, überrascht nicht mehr. Es ändert sich die Ökonomie. Für eine Schwachstelle, die seit 2016 im Linux-Kernel steckt, entstand in weniger als einer Stunde Modellzeit ein funktionierender Remote-Root-Exploit. Wir meinen, dass die knappe Ressource beim Angriff früher die Arbeitszeit qualifizierter Menschen war und diese Knappheit schwindet.

Anthropics Offenlegung zeigt auch Zurückhaltung, was Anerkennung verdient. Das Unternehmen veröffentlichte seinen Exploit nicht, meldete die Schwachstellen zuerst den Herstellern und arbeitet nach eigenen Angaben mit externen Sicherheitsfirmen zusammen, um Funde zu priorisieren und zu validieren. Frandroid merkt an, dass bis zum 30. Oktober keine unabhängige Reproduktion gemeldet wurde. Dennoch erwähnen bereits rund vierzig GitHub-Repositories die Schwachstelle, mindestens sieben davon als Proof of Concept. Die Zurückhaltung eines Labors hindert andere nicht daran, einen eigenen Exploit von Hand oder mit eigenen Werkzeugen zu bauen.

Der Patch ist nicht die Ziellinie

Alle mögen den Satz, dass alle bereits gepatcht sind. Wir würden vorsichtig damit sein. Der Linux-Fix bestand aus vier Zeilen, wurde am 5. Oktober geschrieben und war am 11. und 15. Oktober in stabilen Kerneln enthalten. Doch am Morgen des 2. November führte Ubuntu laut Frandroid seinen Fix für die Versionen 22.04 bis 26.10 weiter als „in Arbeit“, obwohl gepatchte Pakete auf der Tracking-Seite bereits referenziert waren. Red Hat begann erst am 1. November mit der Auslieferung seiner Fixes und stufte den Schweregrad am 30. Oktober auf kritisch hoch, nachdem es und andere Hersteller den Fehler zunächst zwischen 5,9 und 8,1 bewertet hatten.

Das ist die eigentliche Lücke. Den Exploit zu schreiben dauerte ein Modell weniger als eine Stunde, während Priorisierung, Schweregradbewertung, Paketierung und der Neustart des eigenen Servers weiter in menschlichem und bürokratischem Tempo ablaufen. Red Hat hat gewarnt, dass asiatische Unternehmen angesichts der KI-Bedrohungen schneller patchen müssen. Wir würden das auf alle ausdehnen. Wenn ein Modell das Ausnutzen verkürzen kann, ist die entscheidende Verteidigung, das Beheben und Ausrollen zu verkürzen.

Wer es zuerst hat, entscheidet alles

Anthropic hat dieses Modell nicht veröffentlicht, was beruhigend ist und vermutlich auch nur vorübergehend. Die Frage ist, ob Verteidiger gleichwertige Werkzeuge vor den Angreifern erhalten. Wir sind hier vorsichtig optimistisch: Ein Labor, das Schwachstellen vor der Veröffentlichung den Herstellern meldet, erweist Verteidigern einen Dienst. Das funktioniert aber nur, wenn Hersteller das Volumen verkraften. Eine Flut gut validierter kritischer Meldungen kann ein kleines Maintainer-Team ebenso überfordern wie ein Angriff.

Auch eine politische Dimension verdient einen skeptischen Blick. Radio France weist darauf hin, dass Labore mit geschlossenen Modellen wie Anthropic Regulierung gefordert haben, was ihr Geschäftsmodell gegenüber offenen begünstigen könnte. Aus unserer Sicht ist die offensive Fähigkeit ein bequemes Argument für diese Agenda. Sie kann aufrichtig gemeint und trotzdem eigennützig sein.

Was am Montag zu tun ist

Unsere Empfehlung ist praktisch, nicht apokalyptisch. „Patch verfügbar“ sollte als Notfallauslöser gelten, nicht als Ticket für das nächste Quartal. Wer Linux-Server betreibt, prüft den tatsächlichen Kernel-Status, auch bei Cloud- und HWE-Varianten, und startet nach dem Update neu; Container teilen sich den Kernel des Hosts. Wo es noch keinen Fix gibt, verringern die von Frandroid aufgeführten Gegenmaßnahmen (TCP-Pakete mit IPv4-Optionen filtern, MPTCP deaktivieren) die Angriffsfläche, doch laut Red Hat behebt nur ein gepatchter Kernel das Problem.

Das Fazit: Keine Panik wegen des Modells, aber ein wenig Unruhe wegen des eigenen Update-Rhythmus ist angebracht. Der nächste kritische Fehler wird wahrscheinlich schneller kommen als der letzte, und gewinnen werden diejenigen, die die Zeit zwischen der Existenz eines Fixes und seinem Einsatz verkürzen.

Diskussionsthemen

Noch keine Themen: Eröffne das erste.

Weitere Artikel