A Bug Hiding in Plain Sight Since 2003
This week, Nicholas Carlini — a research scientist at Anthropic — presented findings at the [un]prompted AI security conference that are difficult to overstate. Using Claude Code, he discovered multiple remotely exploitable security vulnerabilities in the Linux kernel. One of them, a heap buffer overflow in the NFSv4 driver, had been sitting undetected in the codebase for 23 years.
Twenty-three years. Through every kernel release since 2003. Through every manual code review, every static analysis scan, every fuzzing campaign. Undetected.
"We now have a number of remotely exploitable heap buffer overflows in the Linux kernel," Carlini said. "I have never found one of these in my life before. This is very, very, very hard to do."
How It Works (and Why It Matters)
What's remarkable isn't just the discovery — it's the method. Carlini didn't build a sophisticated custom tool. He wrote a simple shell script that iterated over Linux kernel source files and told Claude Code to look for vulnerabilities in each one. That's it.
The specific NFS bug is technically fascinating. It involves two cooperating NFS clients attacking a Linux NFS server. When the server denies a lock request to Client B (because Client A holds the lock), it tries to write the denial response — including Client A's owner ID, which can be up to 1,024 bytes — into a buffer that's only 112 bytes. The overflow lets an attacker write controlled data into kernel memory over the network.
Finding this required understanding the NFS protocol's state machine across multiple client interactions, tracking buffer allocation sizes across different code paths, and recognizing that a legitimate-but-unusual owner ID length could trigger the overflow. This isn't pattern matching. It's genuine code comprehension.
The Model Generation Gap
Perhaps the most striking data point from Carlini's talk is the performance difference between AI model generations. Claude Opus 4.6 (released February 2026) found the full set of vulnerabilities. When Carlini tried the same approach with Opus 4.1 (released eight months earlier) and Sonnet 4.5, they could only find a small fraction of the same bugs.
This suggests we're at an inflection point. Each new model generation isn't just incrementally better at code analysis — it's qualitatively more capable of the kind of deep reasoning that security research demands.
The Bottleneck Has Shifted
Carlini now has hundreds of potential crashes in the Linux kernel that he hasn't had time to manually validate and report. The bottleneck is no longer finding bugs. It's human review capacity.
"I have so many bugs in the Linux kernel that I can't report because I haven't validated them yet," he said. "I'm not going to send [the maintainers] potential slop, but this means I now have several hundred crashes that they haven't seen because I haven't had time to check them."
This inversion — where AI generates findings faster than humans can process them — is going to become a recurring theme across security, compliance, and code quality. Organizations that figure out how to build efficient human-AI review pipelines will have a significant advantage.
What This Means for Organizations
Three things to think about:
1. Your codebase probably has similar bugs. If the Linux kernel — maintained by thousands of engineers, scrutinized by security researchers worldwide — had a remotely exploitable overflow hiding for two decades, your proprietary codebase almost certainly has undiscovered vulnerabilities too. The question is whether you find them before someone else does.
2. AI-powered security auditing is no longer theoretical. This isn't a benchmark score or a contrived demo. These are real CVEs in production infrastructure that runs most of the internet. The technique is reproducible and, frankly, embarrassingly simple to set up.
3. Attackers will use this too. Carlini framed his talk as a "[un]prompted" security discussion for a reason. The same capability that lets a researcher find and responsibly disclose bugs lets a malicious actor find and exploit them. The asymmetry matters: defenders need to find all the bugs, attackers only need to find one.
The Broader Pattern
This is part of a larger shift in how AI agents interact with complex systems. We're moving from AI that answers questions about code to AI that autonomously reasons about code at a level that matches or exceeds specialist human capability in narrow domains.
The Linux kernel finding is dramatic because of the stakes — kernel vulnerabilities affect billions of devices. But the same capability applies to any large, complex codebase: enterprise applications, financial systems, healthcare infrastructure, government platforms.
The organizations that start integrating AI-powered code analysis into their security workflows now won't just find more bugs. They'll find the kind of bugs that no amount of traditional tooling would catch — the ones that require understanding how dozens of interacting components create emergent vulnerabilities that no single developer ever sees in full.
Looking Ahead
Carlini's research raises an uncomfortable question: what happens when the next model generation is 10x better at this? If Opus 4.6 found what previous models couldn't, what will the next generation uncover?
The answer is almost certainly: a lot more than we're ready for. Organizations should be preparing their vulnerability management and code review processes now — not for the current wave of AI-discovered bugs, but for the tsunami that's coming.
Sources: mtlynch.io writeup, Nicholas Carlini's talk at [un]prompted 2026, Linux kernel commit