Topic analysis

Claude Code Found a Linux Vulnerability Hidden for 23 Years

Nicholas Carlini , a research scientist at Anthropic, reported at the [un]prompted AI security conference that he used Claude Code to find multiple remotely exploitable security vulnerabilities in the Linux kernel, including one that sat undiscovered for 23 years. Nicholas was astonished at how effective Claude Code has been at finding these bugs: We now have a number of remotely exploitable heap buffer overflows in the Linux kernel. 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. —Nicholas Carlini, speaking at [un]prompted 2026 What’s most surprising about the vulnerability Nicholas shared is how little oversight Claude Code needed to find the bug. He essentially just pointed Claude Code at the Linux kernel source code and asked, “Where are the security vulnerabilities?” Nicholas uses a simple script similar to the following: The script tells Claude Code that the user is participating in a capture the flag cybersecurity competition, and they need help solving a puzzle. To prevent Claude Code from finding the same vulnerability over and over, the script loops over every source file in the Linux kernel and tells Claude that the bug is probably in file A, then file B, etc. until Claude has focused on every file in the kernel. In his talk, Nicholas focused on a bug that Claude found in Linux’s network file share (NFS) driver which allows an attacker to read sensitive kernel memory over the network. Nicholas chose this bug to show that Claude Code isn’t just finding obvious bugs or looking for common patterns. This bug required the AI model to understand intricate details of how the NFS protocol works. The attack requires an attacker to use two cooperating NFS clients to attack a Linux NFS server: (1) - Client A does a three-way handshake with the NFS server to begin NFS operations. (2) - Client A requests a lock file. The server accepts, and the client acknowledges the acceptance. (3) - Client A acquires the lock and declares a 1024-byte owner ID, which is an unusually long but legal value for the owner ID. The server grants the lock acquisition. The attacker then spins up a second NFS client, Client B, to talk to the server: (4) Client B does a three-way handshake with the NFS server to begin NFS operations, same as (1) above. (5) Client B requests access to the same lock file as Client A from (2). The NFS server accepts, and the client acknowledges the acceptance. (6) Client B tries to acquire the lock, but the NFS server denies the request because client A already holds the lock. The problem is that at step (6), when the NFS server tries to generate a response to client B denying the lock request, it uses a memory buffer that’s only 112 bytes. The denial message includes the owner ID, which can be up to 1024 bytes, bringing the total size of the message to 1056 bytes. The kernel writes 1056 bytes into a 112-byte buffer, meaning that the attacker can overwrite kernel memory with bytes they control in the owner ID field from step (3). Fun fact: Claude Code created the ASCII protocol diagrams above as part of its initial bug report. This bug was introduced in the Linux kernel in March 2003 : The bug is so old, I can’t even link directly to it because it predates git, which wasn’t released until 2005. Nicholas has found hundreds more potential bugs in the Linux kernel, but the bottleneck to fixing them is the manual step of humans sorting through all of Claude’s findings: 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 because I haven’t had time to check them. —Nicholas Carlini, speaking at [un]prompted 2026 I searched the Linux kernel and found a total of five Linux vulnerabilities so far that Nicholas either fixed directly or reported to the Linux kernel maintainers, some as recently as last week: What’s striking about Nicholas’ talk was how rapidly large language models have improved at finding vulnerabilities. Nicholas found these bugs using Claude Opus 4.6, which Anthropic released less than two months ago . He tried to reproduce his results on older AI models, and discovered that Opus 4.1 (released eight months ago ) and Sonnet 4.5 (released six months ago ) could find only a small fraction of what Nicholas found using Opus 4.6: I expect to see an enormous wave of security bugs uncovered in the coming months, as researchers and attackers alike realize how powerful these AI models are at discovering security vulnerabilities. I'm writing a book of simple techniques to help developers improve their writing. My book will teach you how to: Subscribe to get my latest posts by email.