Claude Code entdeckt Linux-Schwachstelle, die 23 Jahre lang verborgen war

• Claude Code von Anthropic hat automatisch eine remote ausnutzbare Schwachstelle im Linux-Kernel entdeckt und dabei einen Heap-Buffer-Overflow im NFS-Treiber gefunden, der 23 Jahre lang unentdeckt geblieben war
• Mit nichts weiter als dem Prompt „Wo befindet sich eine Sicherheitslücke?“ analysierte es den gesamten Kernel und identifizierte die Schwachstelle nahezu ohne Aufsicht
• Der Fehler ging auf ein Design mit einem festen 112-Byte-Puffer im Kernel-Code von 2003 zurück; nach der späteren Ergänzung der LOCK-Operation fehlte jedoch eine Begrenzung der owner-ID-Länge
• Carlini fand darüber hinaus Hunderte potenzieller Kernel-Schwachstellen, die wegen eines Engpasses bei der menschlichen Verifizierung größtenteils noch nicht gemeldet wurden
• Das aktuelle Modell Claude Opus 4.6 zeigte eine deutlich höhere Erkennungsleistung als frühere Versionen und gilt als Wendepunkt für KI-gestützte Sicherheitsforschung

---

Claude Code entdeckt Linux-Schwachstelle, die 23 Jahre lang verborgen war

• Der Anthropic-Forscher Nicholas Carlini fand mit Claude Code mehrere remote ausnutzbare Schwachstellen im Linux-Kernel
  • Eine davon war eine Buffer-Overflow-Schwachstelle im NFS-(Network File System)-Treiber, die 23 Jahre lang unentdeckt geblieben war
  • Carlini sagte, er habe „eine solche Art von Schwachstelle noch nie selbst gefunden“, und zeigte sich von der Leistung von Claude Code überrascht

• Wie Claude Code Schwachstellen erkennt

  • Claude Code erkennt Sicherheitslücken im Linux-Kernel nahezu ohne Aufsicht
    • Carlini gab einfach den Prompt „Wo befindet sich eine Sicherheitslücke?“ und ließ das Tool die gesamten Kernel-Quelldateien durchlaufen
  • Das verwendete Skript war so aufgebaut, dass Claude Code für jede Datei unter Annahme einer CTF-(Hacking-Wettbewerb)-Situation die schwerwiegendste Schwachstelle in /out/report.txt protokolliert
    • Mit dem Befehl find wurden alle Dateien durchsucht, und für jede Datei wurde Claude Code wiederholt ausgeführt, um Schwachstellen zu finden
  • Das System war so entworfen, dass dieselbe Schwachstelle nicht doppelt gemeldet wird, und analysierte daher alle Dateien des Kernels einzeln

• Die NFS-(Network File System)-Schwachstelle

  • Die wichtigste von Claude Code gefundene Schwachstelle ist ein Heap-Buffer-Overflow im Linux-NFS-Treiber, durch den ein Angreifer über das Netzwerk Kernel-Speicher lesen kann
  • Das Angriffsszenario wird mit zwei zusammenarbeitenden NFS-Clients (Client A, Client B) gegen einen einzelnen NFS-Server durchgeführt
    • Client A fordert mit einer langen owner-ID von 1024 Byte eine Dateisperre an und erhält sie bewilligt
    • Fordert anschließend Client B eine Sperre für dieselbe Datei an, lehnt der Server diese ab und erzeugt eine Antwortnachricht
  • Das Problem ist, dass dieser Antwortpuffer für die Ablehnung nur 112 Byte groß ist, die tatsächliche Nachricht einschließlich owner-ID aber insgesamt 1056 Byte umfasst
    • Dadurch schreibt der Kernel 1056 Byte in einen 112-Byte-Puffer und überschreibt Kernel-Speicher mit vom Angreifer kontrollierten Daten
  • Claude Code erzeugte beim Melden dieser Schwachstelle sogar automatisch ein ASCII-Protokolldiagramm und fügte es dem Bericht hinzu

• Warum sie 23 Jahre lang unentdeckt blieb

  • Der Fehler geht auf im März 2003 in den Linux-Kernel eingeführten Code zurück
    • In der damaligen Commit-Nachricht hieß es, dass NFSD4_REPLAY_ISIZE, ein fester 112-Byte-Puffer, für NFSv4-Operationen wie OPEN und CLOSE ausreiche
    • Als später die LOCK-Operation ergänzt wurde, wurde die Begrenzung der owner-ID-Länge nicht berücksichtigt, wodurch die Schwachstelle entstand
  • Dieser Code stammt aus der Zeit vor der Einführung von Git (2005) und basiert daher auf so altem Code, dass heute nicht einmal ein direkter Link möglich ist

• Hunderte zusätzliche, noch nicht gemeldete Schwachstellen

  • Carlini fand zusätzlich Hunderte potenzieller Linux-Kernel-Schwachstellen, die jedoch wegen eines Engpasses im menschlichen Verifizierungsprozess größtenteils noch nicht gemeldet wurden
    • Er sagte: „Ich kann den Kernel-Maintainern keine unverifizierten Ergebnisse schicken, deshalb gibt es Hunderte von Crashes, die ich noch nicht geprüft habe.“
  • Bislang wurden fünf Schwachstellen bestätigt, die Carlini direkt behoben oder gemeldet hat
    • nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
    • io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
    • futex: Require sys_futex_requeue() to have identical flags
    • ksmbd: fix share_conf UAF in tree_conn disconnect
    • ksmbd: fix signededness bug in smb_direct_prepare_negotiation()

• Fortschritte bei KI-gestützter Schwachstellenerkennung

  • Carlini entdeckte diese Schwachstelle mit Claude Opus 4.6 (zwei Monate vor Veröffentlichung)
    • Mit früheren Versionen wie Opus 4.1 (vor 8 Monaten) und Sonnet 4.5 (vor 6 Monaten) ließ sich dasselbe Ergebnis nicht reproduzieren
    • Das neueste Modell konnte deutlich mehr Schwachstellen erkennen
  • Er prognostizierte: „In den kommenden Monaten wird es eine Welle großangelegter Entdeckungen von Sicherheitslücken geben, wenn sowohl Forscher als auch Angreifer die Stärke dieser KI-Modelle erkennen.“

• Präsentation und weitere Informationen

  • Der Inhalt wurde auf der [un]prompted AI security conference 2026 vorgestellt
  • Der Fund von Claude Code gilt als Beispiel dafür, dass KI die Produktivität realer Sicherheitsforschung drastisch steigern kann

[m3op0w94]

Hoffnungsseite: Linux-Schwachstelle entdeckt
Verzweiflungsseite: Abschaffung des Boundings von curl

[GN⁺]

Hacker-News-Kommentare

• Nicht überraschend. Was im Artikel allerdings nicht erwähnt wird: Claude Code hat auch 1.000 False Positives gefunden, und die Entwickler brauchten 3 Monate, um sie auszusortieren

  • So funktioniert das inzwischen nicht mehr. Das LLM filtert in einer zweiten Pipeline selbst die Bugs heraus, die sich nicht reproduzieren lassen. Zu prüfen, ob eine Schwachstelle tatsächlich auslösbar ist, ist deutlich einfacher, als sie zu finden, daher bleiben am Ende fast nur echte Bugs übrig. Es gibt immer noch viele, die Fortschritte bei LLMs leugnen, aber den praktischen Nutzen kann man kaum bestreiten
  • Würde mich für die Quelle interessieren. So etwas habe ich noch nicht gesehen. Nach meiner Erfahrung lag die False-Positive-Rate von Claude Opus 4.6 bei der Schwachstellenerkennung unter 20 %
  • Tools für statische/dynamische Analyse finden ebenfalls ständig Schwachstellen. Die meisten großen Projekte haben bereits einen Issue-Backlog, den Scanner ausgespuckt haben. Das Problem ist, daraus die tatsächlich gefährlichen Fälle herauszufiltern. Dass Claude einen alten Bug gefunden hat, ist interessant, aber so etwas passiert immer, wenn ein neuer Scanner auftaucht
  • Im Artikel steht nicht, dass es viele False Positives gibt. Dort heißt es eher: „Es gibt noch zu viele Bugs, die noch nicht validiert wurden.“
  • Die Lehre daraus ist nicht, dass Claude Code nutzlos ist, sondern dass es in den richtigen Händen ein mächtiges Werkzeug sein kann

• Neuen Code einfach gesammelt einzufügen und Claude zu fragen: „Was habe ich übersehen? Wo sind Bugs?“, ist ein sehr überzeugender Einstieg für Entwickler, die gerade erst mit AI anfangen. Besonders Threading- oder Distributed-Systems-Bugs findet es schnell. Vermutlich werden gerade massenhaft Krypto-Codebasen analysiert

  • Ich formuliere den Prompt gern so, dass Claude davon ausgeht, dass ein Bug vorhanden ist. Etwa: „In diesem Code ist ein Bug. Kannst du ihn finden?“ oder zusätzlich „Der Bug ist nicht offensichtlich“. Damit hatte ich mehr Erfolg
  • Ich nutze CC/codex fast genau so
  • Ich verwende es eher in der Art: „Das ist Code, den Codex geschrieben hat. Fällt dir etwas Merkwürdiges auf?“

• Statt von einem „versteckten“ Bug zu sprechen, wäre „niemand hat hingeschaut“ treffender. Die Struktur war so, dass in einen 112-Byte-Puffer 1056 Byte geschrieben wurden. Das ist ein Problem, das auch ein statischer Analyzer leicht finden kann, aber wenn man ein LLM anweist, „alle Puffer fester Größe zu prüfen“, kommen auch Halluzinationen dazu. Trotzdem ein guter Ausgangspunkt

  • Die meisten Schwachstellen bleiben bestehen, weil „niemand hingeschaut hat“. Mit wachsender Systemkomplexität wird es für Menschen immer schwerer, noch den Überblick zu behalten. Wenn sich so etwas damit lösen lässt, ist das eine große Nachricht. Statische Analyzer melden alle möglichen Buffer-Copy-Pfade, aber oft ist die Eingabe in der Praxis begrenzt, weshalb das beim Linux-Kernel nicht immer gut passt
  • Dass „niemand hingeschaut hat“, lag in Wahrheit am Personalmangel. Es gab nur begrenzt Leute und Zeit, um Open-Source-Schwachstellen zu finden. Aber jetzt, da die Modelle ausreichend leistungsfähig werden, bricht diese Grenze weg. Das dürfte ein sehr spannendes Jahr werden
  • Man sagt, ein statischer Analyzer hätte das leicht finden können, aber tatsächlich hat es über 20 Jahre lang niemand gefunden. Es ist schon witzig, wie bei allem, was ein LLM Beeindruckendes leistet, sofort die Reaktion kommt: „Ach, das ist doch nichts Besonderes“

• Interessanterweise wären 3 bis 4 der 5 gefundenen Bugs durch den linux-hardened-Patch abgemildert worden. Zum Beispiel durch das Deaktivieren von io_uring, Kernel-Absturz bei UAF oder das Verhindern der Ausnutzung von Heap-Overflows

• Diese Ankündigung nach dem Motto „Wir veröffentlichen eine gefährliche Waffe, also helft mit, die Welt sicherer zu machen. Aber zahlt bitte ein Abo“ ist schon komisch. Das wirkt, als würde ein Biochemiker eine chemische Bombe freisetzen und dann sagen: „Wenn ihr euch davor schützen wollt, müsst ihr zahlen.“ Die Softwarebranche ist momentan wirklich voller Ironie

  • Das ist Unsinn. Das Finden und Melden von Schwachstellen mit dem Versprühen biochemischer Waffen zu vergleichen, ist völlig überzogen

• Ich habe das in mehreren produktiven Codebasen reproduziert, und es gab viele Duplikate, False Positives und nicht ausnutzbare Bugs. Trotzdem waren auch einige echte kritische Schwachstellen (crit) dabei

• Während des Q&A zur Ankündigung habe ich mich gefragt, welches Video im Hintergrund lief. War das eine Exploit-Demo, bei der ein NFS-Bug über USB-Netzwerk ausgenutzt wurde?

• Das ist verwandte Arbeit aus unserem Security Lab. Allein dieses Jahr haben wir mit AI-Sicherheitsagenten 23 Schwachstellen gefunden

  • Security-Lab-Bericht
  • Taskflow-Ausführungsleitfaden

• Die Vorräte an 0-days der Drei-Buchstaben-Behörden (Geheimdienste) dürften stark schrumpfen

• Erwartet künftig nicht mehr Schwachstellenmeldungen, sondern mehr Angriffsversuche