Wenn Ihr Agent eine Sicherheitslücke findet

Nicholas Carlini, Research Scientist bei Anthropic, richtete Claude Code auf den Quellcode des Linux-Kernels und wies es an, Sicherheitslücken zu finden. Der Aufbau: ein 10-zeiliges Bash-Skript sowie ein Docker-Container mit ASAN-instrumentierten Builds. In einer Schleife über die Quelldateien bitten Sie das Modell, nach Fehlern zu suchen, und wechseln dann zur nächsten Datei.¹³

Das Ergebnis, wie Michael Lynch in seiner Zusammenfassung des Vortrags² dokumentiert: ein aus der Ferne ausnutzbarer Heap-Buffer-Overflow im NFSv4 LOCK Replay Cache, der seit März 2003 existiert und damit älter ist als Git selbst. Zwei kooperierende NFS-Clients können sensiblen Kernel-Speicher auslesen, indem sie einen 112-Byte-Puffer mit einer 1.024 Byte langen Lock-Owner-ID überlaufen lassen. Carlini fand bei demselben Durchlauf mindestens vier weitere Kernel-Sicherheitslücken. Zusätzlich lieferte dieselbe Methodik 122 absturzauslösende Eingaben, die an Mozilla übermittelt wurden und von denen 22 CVEs zugewiesen bekamen.³ Er sprach von „mehreren hundert Abstürzen”, die er noch nicht validieren und melden konnte.²

Carlini bestätigte diese Sicherheitslücken und meldete sie den Maintainern. Gefunden hat er sie mit Opus 4.6 — derselben Modellklasse, die Praktiker täglich für Code-Reviews, Refactoring und Feature-Entwicklung einsetzen. Carlini stellte die Ergebnisse im April 2026 auf der [un]prompted AI Security Conference vor.¹

Ja, KI-Agenten können echte Sicherheitslücken finden, die menschliche Experten jahrzehntelang übersehen haben. Ein Anthropic-Forscher nutzte Claude Code mit einem 10-zeiligen Bash-Skript, um einen 23 Jahre alten, aus der Ferne ausnutzbaren Heap-Buffer-Overflow im Linux-Kernel zu entdecken, und erzeugte aus 122 absturzauslösenden Eingaben 22 Firefox-CVEs. Die Methodik benötigt kein eigens entwickeltes Framework: Iterieren Sie über Quelldateien mit ASAN-instrumentierten Builds und fordern Sie das Modell auf, Fehler zu finden.

Kurzfassung

Carlinis Methodik war minimal: Über Quelldateien iterieren, Claude auffordern, in jeder Datei Sicherheitslücken zu finden, und Treffer mit ASAN-Assertions verifizieren. Opus 4.6 fand deutlich mehr Sicherheitslücken als Opus 4.1 (8 Monate älter) oder Sonnet 4.5 (6 Monate älter), was darauf hindeutet, dass die Fähigkeit kürzlich eine Schwelle überschritten hat.² Der Engpass liegt nun bei der menschlichen Validierung, nicht mehr bei der KI-Entdeckung. Diese Verschiebung hat direkte Auswirkungen darauf, wie Praktiker Security-Hooks bauen, Code-Reviews durchführen und über agentengestütztes Auditing nachdenken.

Die wichtigsten Erkenntnisse

• Security Engineers: Die Fähigkeit ist real und entwickelt sich schnell weiter. Wenn Sie agentengestützte Code-Reviews einsetzen, sind Ihre PreToolUse Security-Hooks wichtiger denn je. Nicht, um Claude zu blockieren, sondern um zu steuern, was er mit seinen Funden tun darf.
• Harness-Entwickler: Der Verifikationsengpass („mehrere hundert Abstürze, die ich nicht validiert habe”) ist ein Harness-Problem. Automatisierte Triage, Deduplizierung und Schweregradklassifizierung bilden die nächste Infrastrukturebene.
• Alle anderen: Dasselbe Modell, das 446-fache Performance-Regressionen einführt, findet zugleich Fehler, die 23 Jahre menschlicher Code-Review übersehen haben. Beides ist gleichzeitig wahr.

Die Methodik

Carlinis Ansatz erforderte weder ein spezialisiertes Security-Framework noch ein feinabgestimmtes Modell oder spezielle Prompts. Er beschrieb das Vorgehen als „10-zeiliges Bash-Skript plus Docker-Container”:³

1. Das Ziel mit ASAN-Instrumentierung (AddressSanitizer) kompilieren
2. Über Quelldateien iterieren und das Modell die Sicherheitsrelevanz bewerten lassen
3. Claude Code mit einer Capture-the-Flag-Rahmung für hochrelevante Dateien prompten
4. Mehrere Durchläufe pro Ziel ausführen (5–20, abhängig vom Codebase)
5. Automatisierte Kritik-Agenten zur Verifikation der Funde vor der Offenlegung einsetzen

Die Capture-the-Flag-Rahmung ist entscheidend. Dem Modell zu sagen „dieser Code enthält einen Fehler”, aktiviert einen anderen Modus als „prüfen Sie diesen Code auf Probleme”. Entwickler beobachten dasselbe Muster im Alltag: Claude findet mehr Probleme, wenn Sie sagen, dass ein Problem existiert, als wenn Sie fragen, ob eines existieren könnte.²

Der Durchlauf kostet API-Tokens, nicht Personenmonate. Carlini fand fünf bestätigte Linux-Kernel-Sicherheitslücken und 22 Firefox-CVEs mit einem handelsüblichen Agent CLI.³ Dasselbe Werkzeug, das Ihre Unit-Tests schreibt und Ihre Imports formatiert.

Die Fähigkeitsschwelle

Die auffälligste Beobachtung ist die Kluft zwischen den Modellgenerationen. Carlini versuchte, seine Ergebnisse mit älteren Modellen zu reproduzieren:²

• Opus 4.6 (veröffentlicht ~2 Monate vor dem Vortrag): fand den Heap-Overflow und mehrere weitere Sicherheitslücken
• Opus 4.1 (8 Monate zuvor): fand nur einen kleinen Bruchteil
• Sonnet 4.5 (6 Monate zuvor): fand nur einen kleinen Bruchteil

Zwischen den Modellgenerationen wurde eine Schwelle überschritten. Die Fähigkeit, einen komplexen Codebase im Kontext zu halten, über Datenflüsse hinweg Funktionsgrenzen zu überschreiten und subtile Spezifikationsabweichungen zu erkennen, scheint eher sprunghaft aufgetreten zu sein als sich graduell verbessert zu haben.

Carlini formulierte es deutlich: „Ich habe in meinem Leben noch nie eine davon gefunden. Das ist sehr, sehr, sehr schwer. Mit diesen Sprachmodellen habe ich eine ganze Reihe.”²

Das Paradox

Dieselbe Agentenarchitektur, die Performance-Regressionen einführt — 118 Funktionen mit Verlangsamungen zwischen 3x und 446x — findet zugleich Sicherheitslücken, die jahrzehntelange menschliche Expertenreview übersehen hat. Beides sind komplementäre Aspekte desselben Fähigkeitsprofils. Vulnerability-Research ist im Kern Mustererkennung gegen bekannte Klassen (Buffer-Overflows, Use-after-free, Integer-Signedness-Probleme), was eine LLM-Stärke ist.⁴ Performance-Optimierung verlangt das Gegenteil: das Nachdenken über spezifische Ausführungskontexte, Cache-Verhalten und algorithmische Komplexität. Das Modell erkennt einen Buffer-Overflow über Millionen von Codezeilen hinweg, kann Ihnen aber nicht sagen, dass eine Hash Map für Ihr Zugriffsmuster langsamer ist als ein sortiertes Array. Bauen Sie Ihren Harness entsprechend: mit Security-Hooks, die Funde kennzeichnen, und Performance-Hooks, die vor dem Commit messen.

Der Verifikationsengpass

Carlinis aufschlussreichstes Eingeständnis: „Ich habe so viele Bugs im Linux-Kernel, die ich nicht melden kann, weil ich sie noch nicht validiert habe.”²

Der Engpass liegt inzwischen bei der Triage, nicht mehr bei der Entdeckung. Potenzielle Sicherheitslücken zu finden, kostet weniger als zu bestätigen, dass sie real sind. Diese Umkehrung schafft ein neues Infrastrukturproblem für Security-Teams:

Entdeckung ist automatisiert. Ein Agent kann einen Codebase in Stunden durchsuchen.

Verifikation ist manuell. Jede potenzielle Sicherheitslücke benötigt einen Proof-of-Concept, eine Impact-Bewertung und einen verantwortlichen Offenlegungsprozess.

Triage ist die Lücke. Hunderte von agentengenerierten Funden in echte Sicherheitslücken, False Positives und niedrigschwelliges Rauschen zu sortieren, ist die Arbeit, für die es noch kein gutes Tooling gibt.

Das Muster spiegelt agentengestützte Code-Reviews wider: Der Agent produziert Rohoutput schneller, als Menschen ihn bewerten können. Der Wert liegt nicht in der Erzeugung, sondern in der Infrastruktur, die den Output verarbeitet, filtert und weiterleitet.

Für Harness-Entwickler bedeutet das: Der nächste wertvolle Hook ist kein Security-Scanner, sondern ein Security-Triage-System — Deduplizierung, Schweregradklassifizierung, False-Positive-Filterung und automatische Proof-of-Concept-Erzeugung. Die Governance-Hooks, die den Agentenoutput kontrollieren, sind wichtiger als die Scan-Fähigkeiten selbst.

Was das für Praktiker bedeutet

Wenn Sie Claude Code auf Produktions-Codebases einsetzen, betreiben Sie bereits ein System, das echte Sicherheitslücken finden kann. Die Frage ist nicht, ob die Fähigkeit existiert, sondern ob Ihr Harness mit dem umgehen kann, was der Agent findet.

Drei praktische Schritte:

Fügen Sie Ihrer Review-Pipeline einen Security-Sweep hinzu. Ein PostToolUse-Hook auf Write/Edit kann einen gezielten Security-Scan auf geänderten Dateien auslösen. Der Hook liest den Dateipfad von stdin (Claude Code übergibt Event-JSON auf stdin an Hooks):

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking, runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

Der obige Hook ist ein Ausgangspunkt, nicht produktionsreif. Sie würden Deduplizierung, Schweregradfilterung und Rate Limiting ergänzen. Das Grundmuster aber entspricht Carlinis Methodik: eine Schleife über Dateien mit einem gezielten Prompt.³

Bauen Sie eine Triage-Infrastruktur auf. Rohe Sicherheitslücken-Funde ohne Schweregradklassifizierung sind Rauschen. Wenn Ihr Agent pro Durchlauf 50 Funde produziert, benötigen Sie automatisierte Deduplizierung und Priorisierung, bevor ein Mensch die Liste zu Gesicht bekommt. Der Engpass ist ein Harness-Problem, kein Modellproblem.

Akzeptieren Sie das Paradox. Dasselbe Modell, das Performance-Leitplanken braucht, ist bei der Security-Mustererkennung tatsächlich hervorragend. Gestalten Sie Ihren Harness so, dass er die Stärke nutzt und die Schwäche kompensiert: Security-Hooks, die scannen. Performance-Hooks, die messen. Quality-Hooks, die verifizieren. Jeder deckt ab, was die anderen übersehen.

Die 23 Jahre alte Linux-Sicherheitslücke war nicht versteckt. Sie lag offen da, in einer Datei, die tausende Ingenieure gelesen hatten. Das Modell fand sie, weil Mustererkennung im großen Maßstab genau das ist, was diese Systeme tun. Die Lehre lautet nicht, dass Agenten bei Sicherheit besser sind als Menschen. Die Lehre lautet, dass Agenten eine andere Fläche abdecken — und der Harness, der beides orchestriert, macht die Kombination erst zuverlässig.

Update (7. April 2026): Anthropic kündigte Project Glasswing an, ein neues Modell namens Claude Mythos, das Carlinis Ansatz auf tausende Zero-Days über alle wichtigen Plattformen hinweg skaliert. Mythos ist weiterhin auf 12 Partner beschränkt und nicht öffentlich verfügbar. Der obige Beitrag behandelt Carlinis ursprüngliche Forschung; die Fortsetzung behandelt die Produktisierung.

Quellen

Häufig gestellte Fragen

Kann ich Carlinis Ansatz mit Claude Code reproduzieren?

Carlini dokumentierte die Methodik im Podcast-Interview.³ Die Kernschleife: mit ASAN kompilieren, über Quelldateien iterieren, Claude mit einer Capture-the-Flag-Rahmung prompten, Treffer verifizieren. Carlini berichtete, dass Opus 4.6 deutlich mehr Sicherheitslücken fand als ältere Modelle, weshalb Ergebnisse mit anderen Modellgenerationen abweichen können.

Heißt das, KI-Agenten sind besser als Menschen darin, Sicherheitslücken zu finden?

Nein. Es heißt, Agenten decken eine andere Fläche ab. Agenten sind stark in der Mustererkennung gegen bekannte Vulnerability-Klassen über große Codebases hinweg. Menschen sind stark im Verstehen neuartiger Angriffsvektoren, fachlicher Logikfehler und kontextabhängiger Sicherheitseigenschaften. Die Kombination ist stärker als jede Seite allein.

Sollte ich mir Sorgen machen, dass Angreifer diese Fähigkeit nutzen?

Carlini warnte ausdrücklich vor „einer großen Welle, die auf uns zukommt”. Dieselbe Fähigkeit, die Verteidigern hilft, Sicherheitslücken zu finden, steht Angreifern zur Verfügung. Die Asymmetrie besteht darin, dass Verteidiger Triage und Patching automatisieren können, während Angreifer weiterhin Exploits entwickeln müssen. Aber der Abstand bei der Entdeckung schrumpft.