An AI Found Five Linux Kernel Bugs. Now What?

TV
Thiago Victorino
8 min read
An AI Found Five Linux Kernel Bugs. Now What?
Listen to this article

In early April 2026, Nicholas Carlini, a research scientist at Anthropic, presented results from a vulnerability-discovery experiment at [un]prompted 2026. The setup was deliberately simple: a bash script, a find command to iterate through Linux kernel source files, and Claude with a prompt framing each file as a capture-the-flag challenge. Minimal human oversight. No specialized tooling.

The results were not simple. Carlini reported five confirmed vulnerabilities in the Linux kernel, including a remotely exploitable heap buffer overflow in the NFSv4.0 LOCK replay cache. That vulnerability had been present since March 2003. Twenty-three years, undetected.

“I have never found one of these in my life before,” Carlini said of the heap buffer overflows. “This is very, very, very hard to do.”

Hard for humans. The AI found it by reading source code, file by file, looking for patterns that matched known vulnerability classes.

The Technical Details Matter

The NFS vulnerability is worth understanding because it illustrates a category of bug that has historically required deep domain expertise to find.

The NFSv4.0 LOCK replay cache allocates a 112-byte buffer (NFSD4_REPLAY_ISIZE) to store cached responses. A LOCK response, however, can reach 1,056 bytes when two cooperating NFS clients exploit the owner ID field, which permits values up to 1,024 bytes. The result: a 944-byte heap buffer overflow, readable over the network. A remotely exploitable kernel memory read, not a theoretical concern.

Four other vulnerabilities followed: an out-of-bounds read in io_uring/fdinfo, a futex flag mismatch, and two bugs in ksmbd (a use-after-free and a signedness error). All five were reported to maintainers and fixed.

Then Carlini mentioned the backlog. “I have so many bugs… I haven’t had time to check them.” He described “several hundred crashes” that had not yet been validated.

That sentence deserves a second read.

The Validation Bottleneck

Several hundred unvalidated crashes. This is the first governance problem, and it has nothing to do with whether AI should be doing security research.

Carlini’s methodology generated potential vulnerabilities faster than a human researcher can confirm them. Each crash needs triage: is it exploitable? Is it a duplicate? Does the fix introduce regressions? That work is slow, careful, and requires the same deep expertise that made finding these bugs hard in the first place.

We have entered an asymmetry. The discovery side of vulnerability research just got orders of magnitude faster. The validation side did not. The bottleneck moved from “can we find bugs?” to “can we confirm and fix them fast enough?”

For defenders, this is a resource allocation problem. Security teams already struggle to keep pace with known vulnerability disclosures. A sudden increase in AI-discovered bugs will compound the backlog. The question becomes organizational: who triages this volume? With what authority to prioritize? Under what timelines?

The Capability Trajectory

Carlini’s presentation included a model comparison that should concern anyone thinking about this on a longer timeline.

Claude Opus 4.6 (released approximately two months before the presentation) dramatically outperformed Claude Opus 4.1 (released eight months prior) and Claude Sonnet 4.5 (released six months prior). The improvement was not incremental. It was a step function in effectiveness at finding real vulnerabilities in production kernel code.

Six to eight months between model generations. Substantial capability gains each cycle. Project that forward two or three iterations and the volume of discoverable vulnerabilities per unit of researcher time becomes very large.

For governance, the trajectory invalidates a common assumption: that AI-powered vulnerability discovery is an edge case, a research curiosity, something that requires specialized setups and expert oversight. Carlini’s methodology was a bash script. The prompt was a CTF framing. The flag --dangerously-skip-permissions is right there in the name, telling you what guardrails were bypassed.

A single researcher with a shell script found a 23-year-old kernel vulnerability. The technique is already accessible to anyone with API access.

The Dual-Use Reality

Here is where governance conversations tend to stall. The same capability that lets a researcher find and responsibly disclose vulnerabilities lets an attacker find and silently exploit them.

Carlini works at Anthropic. He disclosed responsibly. The bugs were fixed. But the methodology is public. The models are commercially available. The bash-script-and-find approach requires no proprietary infrastructure. Responsible disclosure happened here because a responsible person was doing the research. The technique does not carry that property with it.

As we argued in AI Governance IS Cybersecurity, the organizational separation between AI governance teams and cybersecurity teams creates blind spots at exactly the intersection where these threats emerge. An AI governance team might track model capabilities. A cybersecurity team might track vulnerability disclosures. Neither team, working alone, connects “model capabilities improved by 3x in eight months” with “our attack surface just expanded by a corresponding factor.”

The dual-use problem is not new. Every security tool is also a potential attack tool. What is new is the speed at which capability is scaling and the low barrier to replication.

What “Enormous Wave” Means in Practice

Michael Lynch, who reported on Carlini’s presentation, predicted “an enormous wave of security bugs uncovered in coming months.” That prediction deserves examination because its implications differ depending on who is doing the uncovering.

If the wave comes primarily from responsible researchers and security firms, the result is a painful but manageable increase in patch volume. Kernel maintainers will be overwhelmed. Downstream distributions will struggle with the cadence. But the bugs get fixed.

Should the wave come simultaneously from adversaries, the result is a period where known-to-attackers-but-not-yet-patched vulnerabilities proliferate. The window between AI-powered discovery and human-paced patching becomes the exploitable surface.

The likely reality is both, happening in parallel, with no coordination between them.

Organizations that depend on Linux (which is to say, nearly all of them) should be asking operational questions now. How fast can we apply kernel patches? Do we have compensating controls for the period between disclosure and patch deployment? Is our vulnerability management process designed for the current volume of disclosures, or for a volume that might be three to five times larger within a year?

Three Governance Implications

First: model access policies need security context. Organizations providing AI model access to employees or contractors should understand that those models can now be used for vulnerability discovery with minimal setup. The point is not restriction. The point is awareness: the capability exists, and threat models should incorporate it. An employee with Claude access and kernel source code is, whether they intend it or not, equipped to find zero-days.

Second: vulnerability disclosure infrastructure needs to scale. The current system of responsible disclosure depends on human-speed processes: researcher contacts maintainer, maintainer triages, patch is developed, patch is reviewed, patch is released. If AI multiplies the discovery rate by 10x or 100x, every step in that chain needs to handle proportionally more volume. The bottleneck is no longer finding bugs. It is processing them.

Third: the defensive application is the strategic priority. The same technique Carlini used can be turned inward. Organizations can run AI-powered vulnerability scans against their own codebases before attackers do. Not a theoretical possibility. A bash script. The question is whether security teams have the authorization, the budget, and the organizational support to do it proactively.

The Uncomfortable Timeline

Here is what makes this finding hard to sit with.

The NFS vulnerability existed for 23 years. During that time, the Linux kernel went through thousands of code reviews, multiple security audits, and continuous scrutiny from one of the largest open-source communities in the world. Nobody found it.

An AI, prompted with a CTF framing and pointed at the source code file by file, found it in a single pass.

This does not mean human code review is worthless. It means the attack surface of long-lived codebases contains vulnerability classes that human reviewers consistently miss. And it means the tools to find those hidden vulnerabilities are now available to anyone, not just to researchers at AI labs.

The governance response cannot be “prevent people from using AI for security research.” That ship has sailed. The response has to be structural: accelerate defensive scanning, invest in automated patch validation, redesign vulnerability management workflows for higher volume, and recognize that the speed of AI-powered discovery has permanently changed the economics of software security.

Five bugs found. Several hundred crashes unvalidated. A capability curve steepening with every model release. The question for organizations is not whether this affects them. It is whether they will run these tools against their own code before someone else does.


This analysis synthesizes Michael Lynch’s reporting on Claude Code Found a Linux Vulnerability Hidden for 23 Years (April 2026), based on Nicholas Carlini’s presentation at [un]prompted 2026.

Victorino Group helps organizations integrate AI capabilities into their security governance before the threat model forces the conversation. Let’s talk.

All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →

If this resonates, let's talk

We help companies implement AI without losing control.

Schedule a Conversation