500 Zero-Days in 30 Days: The AI Security Audit Nobody Asked For

Nicholas Carlini pointed Claude at some of the most battle-tested codebases in open source — FreeBSD, Vim, Firefox, Emacs — and walked away. When he came back, the AI had found working exploits for bugs that human security teams had missed for decades. The campaign, dubbed MAD Bugs, has produced over 500 high-severity zero-days in about a month, and it's forcing a reckoning with how we think about software auditing.

#The FreeBSD Exploit That Started It All

The most dramatic result is CVE-2026-4747: a stack buffer overflow in FreeBSD's kgssapi.ko module, which handles RPCSEC_GSS authentication for the kernel-level NFS server. The vulnerability is dead simple — the kernel copies an RPCSEC_GSS credential body into a 128-byte stack buffer without verifying that the payload fits the 96 usable bytes after a 32-byte fixed header. Because this module talks to the network via port 2049/TCP, the flaw is remotely exploitable.

Claude didn't just find the bug. It wrote two complete, working remote root exploits — each succeeding on its first attempt after roughly four hours of compute time. Carlini's write-up describes stepping away from his computer and returning to find the AI had independently solved six distinct technical problems in the exploit chain without any human guidance. Six sub-problems. Zero human hints. First-try success on both exploit variants.

FreeBSD's security advisory credits "Nicholas Carlini using Claude, Anthropic" — probably the first time a major OS vendor has credited an AI system as a co-discoverer in a kernel-level CVE. That credit line alone tells you something has shifted.

This isn't a toy demo on a CTF challenge. RPCSEC_GSS is authentication infrastructure that's been shipping in production FreeBSD kernels for years, reviewed by kernel developers, stress-tested in enterprise deployments, and generally assumed to be solid. The buffer overflow had been sitting there, exploitable from the network, the entire time.

#MAD Bugs by the Numbers

MAD Bugs — Month of AI-Discovered Bugs — has been running through April 2026. The methodology is almost insultingly simple: point Claude Opus 4.6 at a codebase through standard conversational prompts and ask it to find exploitable patterns. No custom tooling. No fine-tuned models.

That last row deserves a double take. Emacs maintainers looked at a critical remote code execution vulnerability discovered by an AI and decided not to fix it.

#Why Human Auditors Missed These for Years

The common thread across all 500+ discoveries is that these bugs live in code paths that humans scan past. Not because the code is obscure — because it's boring. Buffer handling in authentication modules. Parsing logic in text editors that hasn't changed since the Clinton administration. The kind of C that's been "working fine" for fifteen years and gets skimmed during review because everyone assumes someone else already checked it.

AI doesn't get bored. It doesn't skip the tedious parts. And critically, it doesn't carry the assumption that old, well-reviewed code must be safe. What Carlini's approach reveals is that the bottleneck in security research was never about the sophistication of analysis techniques — it was about raw coverage. Humans are excellent at finding subtle logical bugs when they know where to look. They're terrible at looking everywhere, at everything, systematically.

There's a pattern-matching dimension too. LLMs trained on vast codebases have internalized millions of vulnerability patterns — how buffer copies fail, how off-by-one errors cascade, how authentication state machines get confused. When Claude examines a memcpy into a stack buffer, it's drawing on statistical knowledge of how similar code has failed across thousands of projects. Traditional static analysis tools check against explicit rules. The model checks against implicit patterns learned from the entire history of software bugs. Turns out that second approach catches things the first one doesn't.

#The Window Has Collapsed

Here's the uncomfortable reality: everything Carlini did is reproducible by anyone with an API key and a weekend. The same conversational pipeline that found 500 defensive vulnerabilities works identically for offense. The window between public vulnerability disclosure and working exploit code has compressed from weeks to hours.

This is precisely what Anthropic's own leaked Mythos documentation warned about — models that "presage an upcoming wave of models that can exploit vulnerabilities in ways that far outpace the efforts of defenders." The irony of that warning leaking from Anthropic's misconfigured CMS is its own kind of lesson about the state of security in 2026.

#What To Do If You Ship Code

If you maintain an open source project or ship anything with C/C++ components, the calculus has changed overnight. Some practical steps that actually matter:

Run AI audits on your own code before someone else does. You don't need Carlini's research credentials. Claude, GPT-5.4, or even Gemma 4's 31B model can do credible vulnerability scanning through standard API access. Feed it your authentication modules, your parsing code, your buffer handling. The API cost is trivial compared to a CVE disclosure cycle.

Prioritize the boring code. The MAD Bugs pattern is unambiguous — the highest-severity findings cluster in infrastructure code that nobody has closely examined in years. NFS authentication handlers. Terminal escape sequence parsers. Config file readers written before your senior engineer joined the company. If a module hasn't been seriously reviewed since 2019, that's exactly where to point the AI first.

Rethink your disclosure timelines. If you're a maintainer, assume that once a vulnerability class is public, working exploits will exist within hours, not weeks. The traditional 90-day responsible disclosure window was designed for a world where exploit development required significant human effort. That assumption no longer holds.

Don't be the Emacs maintainers. When a critical RCE lands in your inbox, the source of the discovery doesn't change the severity. Patch it.

The first month of results from MAD Bugs suggests that most production software has far more exploitable surface area than anyone assumed. The real question isn't whether AI will transform vulnerability research — Carlini just proved it already has. The question is whether your defensive tooling catches up before someone else's offensive tooling finds your bugs first.