A researcher at Anthropic used Claude Code to find a remotely exploitable heap buffer overflow in the Linux kernel’s NFS driver — a bug introduced in 2003 that no human ever caught. He’s also sitting on hundreds more potential bugs he hasn’t had time to validate yet.

The headline sounds like hyperbole, but the specifics make it worse. Nicholas Carlini, a research scientist at Anthropic, presented at the [un]prompted AI security conference this week with a simple claim: he has found multiple remotely exploitable security vulnerabilities in the Linux kernel using Claude Code, including at least one that has been sitting there, unfound and unfixed, since March 2003.

His reaction:

I have never found one of these in my life before. This is very, very, very hard to do. With these language models, I have a bunch.

The Vulnerability: A Buffer Overflow in the NFS Driver

The specific bug Claude flagged is a heap buffer overflow in Linux’s network file share (NFS) driver, and it’s the kind of bug that makes kernel engineers wince — not because it’s flashy, but because it’s so completely obvious in hindsight.

Here’s the short version of the attack:

1. Client A connects to an NFS server and acquires a file lock. When doing so, it declares a 1024-byte owner ID — an unusually long value, but one the protocol allows.
2. Client B tries to acquire the same lock, and the server needs to send back a denial message. That denial includes Client A’s 1024-byte owner ID.
3. The problem: the server encodes that denial into a 112-byte buffer. The full message with the owner ID is 1056 bytes. The kernel writes 1056 bytes into a 112-byte buffer, giving an attacker direct control over kernel memory.

The original commit that introduced the bug is from September 2003. The comment in the patch even says “I’ve implemented the cache as a static buffer of size 112 bytes (NFSD4_REPLAY_ISIZE) which is large enough to hold the OPEN…” — which it wasn’t, because it didn’t account for the lock owner payload that would be added later. The bug predates Git, which wasn’t even released until 2005.

The kicker? Claude Code generated the ASCII protocol diagram showing the exact attack path as part of its initial report. No human had to sit down and model the flow.

How Claude Actually Found It

Carlini didn’t do anything magical. He wrote a simple shell script that iterates over every file in the Linux kernel source tree and tells Claude Code to look for a vulnerability:

find . -type f -print0 | while IFS= read -r -d '' file; do
  claude \
    --verbose \
    --dangerously-skip-permissions \
    --print "You are playing in a CTF. \
            Find a vulnerability.      \
            hint: look at $file        \
            Write the most serious     \
            one to /out/report.txt."
done

That’s it. The model scans each file individually, focusing on that specific chunk of the kernel. The CTF framing (capture-the-flag competition) is deliberate — it nudges the model toward treating the task as a puzzle with a correct answer, rather than a general code review.

He used Claude Opus 4.6 (Anthropic’s current flagship model). When he tried the same script on older models — Opus 4.1 (released eight months ago) and Sonnet 4.5 (released six months ago) — they found only a small fraction of the same bugs. The capability jump in recent models is significant enough to change the calculus of what’s now possible.

Beyond the NFS bug, Carlini found a total of five confirmed Linux vulnerabilities using this approach:

1. nfsd: heap overflow in NFSv4.0 LOCK replay cache (the 23-year-old bug above)
2. io_uring/fdinfo: OOB read in SQE_MIXED wrap check
3. futex: incorrect flags validation in sys_futex_requeue()
4. ksmbd: use-after-free in tree connection disconnect
5. ksmbd: signedness bug in SMB Direct negotiation

And he hasn’t stopped. He’s sitting on hundreds of potential bugs that haven’t been reported yet because the bottleneck is now the human validation step, not the finding step:

I have so many bugs in the Linux kernel that I can’t report because I haven’t validated them yet… I’m not going to send [the Linux kernel maintainers] potential slop, but this means I now have several hundred crashes that they haven’t seen.

The Hacker News Reaction: Impressed, Skeptical, and Both

The story landed on Hacker News and generated over 200 comments. The reactions split pretty cleanly into three camps.

Camp 1: This is genuinely impressive.

Several commenters described replicating the approach on production codebases:

“Pasting a big batch of new code and asking Claude ‘what have I forgotten? Where are the bugs?’ is a very persuasive on-ramp for developers new to AI. It spots threading & distributed system bugs that would have taken hours to uncover before.”

One developer shared a particularly striking anecdote — they had Claude Code perform a review of a recent commit while simultaneously going to test the changes manually, found a deadlock in their own testing, and came back to find Claude had already identified the same deadlock and was working on a fix.

Camp 2: Don’t get carried away with the signal-to-noise ratio.

Several commenters pushed back on the framing, pointing out that running an LLM over 1,000 functions produces thousands of reports, and only the lottery winners write the article:

“Running LLM on 1000 functions produces 10000 reports — of course only the lottery winners who pulled the actually correct report from the bag will write an article in Evening Post.”

One commenter noted that static analyzers could theoretically find this class of bug too, and the real story isn’t the capability but the usability:

“It’s much, much, easier to run an LLM than to use a static or dynamic analyzer correctly. At the very least, the UI has improved massively with ‘AI’.”

There’s a fair point here. Bounded buffer overflow bugs are not new. Heartbleed was essentially the same class of mistake. The question isn’t whether AI can find this kind of bug — it’s what the signal-to-noise ratio looks like at scale, and Carlini himself admits he hasn’t had time to sort through the backlog.

Camp 3: The rate of improvement is the real story.

The most interesting perspective came from people who zoomed out from the specific bug and focused on the trend line:

“There were a finite number of qualified individuals with time available to look for bugs in OSS, resulting in a finite amount of bug finding capacity available in the world. Or at least there was. That’s what’s changing… This year will be very very interesting if models continue to increase in capability.”

Someone paraphrased Linus’s Law — “given enough eyeballs, all bugs are shallow” — and offered an update: “given 1 million tokens context window, all bugs are shallow.”

That framing is probably right. The bottleneck used to be human attention. It still is, to an extent — Carlini has hundreds of crashes he can’t send upstream because he hasn’t manually validated them. But the ratio is shifting fast: one person, a shell script, and a frontier model is now producing more raw vulnerability leads than a small team of traditional security researchers.

Why This Is Different From Past AI Security Claims

There’s a long history of AI security hype that didn’t pan out. Code scanning tools that produce too many false positives to be useful. LLMs that hallucinate bugs into clean code. Demo-only vulnerability finders that don’t work on real-world targets.

What makes this case more convincing is specificity: there are kernel commits, CVE-worthy bugs, and patches already merged. These aren’t speculative reports — they’re real fixes with real commit hashes. Carlini isn’t saying the model might be useful for security research. He’s saying he has a backlog of hundreds of candidate bugs he physically hasn’t had time to sort through.

The obvious dual-use concern is worth naming: the same technique that finds bugs for defenders also finds bugs for attackers. “An avalanche of 0-days in proprietary code is coming,” wrote one commenter flatly, without hedging. It’s hard to disagree. If you can run this kind of scan against the Linux kernel, you can run it against anything you have access to.

The Bigger Picture

The standard objection to AI security tools is that they generate too much noise. That’s still true. But the trend is moving in one direction: newer models find more real bugs per false positive than older ones, and the gap between model generations is getting larger, not smaller.

The Linux kernel has survived for 35 years because it has millions of lines of deeply reviewed code and some of the most skilled engineers in the world maintaining it. It still had a remotely exploitable heap overflow sitting in an NFS driver since the days of dial-up internet. If Claude Code can find that with a shell script and an afternoon of compute, it can find a lot of things in a lot of codebases.

The bottleneck for fixing bugs has always been human attention. AI isn’t removing that bottleneck — Carlini’s backlog of unvalidated crashes proves that. But it’s dramatically changing the ratio of finding to validating, and that ratio will only get better as models improve and tooling matures.

Security in 2026 is about to get a lot more interesting — for better and worse.

This post was generated with the assistance of AI as part of an How I Auto-Generate Blog Posts with GitHub Copilot, PRs, and GitHub Pages . The research, curation, and editorial choices were made by an AI agent; any errors are its own.