Nicholas Carlini is a research scientist at Anthropic. He gave a talk at [un]prompted 2026 this week and said something that should concern every enterprise security team running Linux infrastructure.
He used Claude Code to scan the Linux kernel source. Simple prompts. Loop over every file. Ask where the security vulnerabilities are. The framing was a CTF game, but the method was brutally unsophisticated.
He found a remotely exploitable heap buffer overflow in the NFS driver that had been sitting in the Linux kernel for 23 years. He has found several more since. His quote from the talk: “I’ve never found one of these in my life before. Now I have a bunch.”
This is the fourth AI-discovered zero-day story in one week. FreeBSD, Vim, Emacs, and now Linux. The pile-up is not a coincidence.
What He Found
The vulnerability is in Linux’s NFS driver. Network File System, the protocol your servers probably use to share files across machines. The bug allows a remote attacker to read sensitive kernel memory over the network using two cooperating NFS clients.
This is not a local privilege escalation. This is not something that requires a logged-in user. This is a heap buffer overflow reachable from a network connection. Deploy NFS, accept connections from untrusted networks, and the kernel might leak memory to an attacker sitting on that network.
The bug was in the code for 23 years. Kernel security researchers, red teams, auditors, andAutomated tools have looked at this code. The vulnerability sat there, undiscovered, until a research scientist at an AI company ran a simple prompt loop over the source.
Why This Was Hard for Humans to Find
Carlini’s point about the NFS vulnerability specifically is worth sitting with. The exploit requires deep understanding of the NFS protocol state machine and lock handling. This is not a obvious buffer overflow that pattern-matching tools would catch. It requires understanding the protocol at a level that most security researchers would not bother with for an old NFS implementation.
Claude Code found it anyway. The prompt loop approach did not rely on sophisticated techniques. It just kept asking the model to look at files and identify problems. The model could reason about the protocol state machine because language models can reason about protocol semantics in a way that automated static analysis tools historically cannot.
This is the asymmetry Carlini is pointing at. Human researchers could have found this. They would need the right specialization, the right motivation, and enough time to deep-dive a legacy NFS implementation. AI does not need any of that. It needs a prompt and a codebase.
The Practical Implication for Your Infrastructure
If you run Linux servers with NFS exposed to any network you do not fully control, patch. The kernel commit exists. Stable kernel releases have the fix. A remote attacker on that network can potentially read kernel memory. Kernel memory often contains secrets: keys, credentials, session tokens.
Now add the broader context. This is the fourth critical vulnerability found by AI red-teaming this week alone. FreeBSD kernel RCE. Vim modeline RCE. Emacs Git integration RCE. Linux kernel remote memory read. All found by pointing AI at codebases and asking questions.
The vulnerability surface of the entire open-source ecosystem just got a lot more scrutinized. That is good for patching. It is also a reminder that the question every security team needs to answer is not whether AI will find vulnerabilities in their code. It is whether someone else’s AI already has.
Carlini found a 23-year-old bug by accident, while giving a conference talk. The people who were looking for Linux kernel zero-days before this week did not find it. The AI found it in an afternoon.
Sources:
– Michael Lynch — Claude Code Found Linux Vulnerability
– Carlini Talk at [un]prompted 2026 (YouTube)
– Linux Kernel Patch (Git)
