Claude Writes 180 Million Lines of Proof to Catch Bugs Fuzzers Missed for Years

Anthropic published research on October 22 showing that Claude, working alongside formal-methods startup Theorem, formally verified 123 open-source libraries against 239 fuzz-test entry points — producing roughly 180 million lines of machine-checked proof code in the process. The team describes it as the first large-scale use of AI to formally verify production software at the level of compiled machine instructions, and the proofs uncovered real bugs that years of automated fuzz testing had structurally no way of finding.

The distinction matters because of a hard logical limit in how formal proofs work: a proof that all inputs in a defined space are safe cannot be completed if any unsafe input exists within that space. That means the act of attempting verification is itself a systematic search for counterexamples — one that covers territory a fuzzer never visits.

Why Fuzzing Has a Structural Ceiling

Google's OSS-Fuzz project has continuously tested hundreds of open-source libraries since 2016, feeding programs randomly mutated inputs and watching for crashes, memory corruption, and AddressSanitizer violations. It has found tens of thousands of bugs. What it cannot do is test an input it never generates.

OSS-Fuzz typically caps input sizes at around one megabyte. That is not an arbitrary choice — larger inputs slow fuzzing throughput substantially, reducing the number of test cases per second. The tradeoff is acceptable for most threat models, but it leaves a gap.

In one of the libraries Claude was tasked with verifying, a decompressor contained a counter-underflow vulnerability that only triggers with an input of approximately 20 megabytes arranged in a highly specific layout. Fuzz testing at standard scales would never generate that input. The proof attempt forced Claude to reason about all inputs up to 64 MB — and when it tried to prove safety for the full space, the proof failed, because the 20 MB counterexample exists. The bug surfaced as a logical consequence of the verification attempt, not from a lucky random hit.

Anthropic's team says the approach has now found hundreds of bugs this way across the libraries under examination.

Rocq Checks the Proofs — Claude Does Not Grade Its Own Work

The proofs Claude generates are written in Rocq, a formal proof assistant developed at INRIA that uses the Calculus of Inductive Constructions as its foundational logic. Rocq's kernel checks every inference step in a submitted proof against strict logical rules. A proof that passes Rocq is mathematically guaranteed to be valid within the model — the system does not accept approximate or probabilistic arguments.

This architecture is important for credibility: Claude produces the proofs, but Rocq — an independently developed external system — verifies them. The AI's output is not self-certified.

Verification runs at the level of compiled RISC-V machine code rather than C or C++ source. That is technically harder, because the proof must account for all the transformations a compiler applies. Theorem contributed the formal semantics that make it possible: mathematical models of RISC-V instruction behavior and Linux process state, which give Rocq a precise foundation for reasoning about what a binary actually does.

391 Lines of C, 630,000 Lines of Proof, and a Path Toward Shared Coverage

The proof-to-code ratio illustrates how demanding formal verification is in practice. For a single entry point in the cJSON library — 391 lines of C — Claude produced approximately 630,000 lines of Rocq proof. The proof must cover not only the 391 lines under examination but every underlying library function those lines invoke.

To handle the volume, Claude wrote tools that automatically generated more than half the proof content. The proofs also benefit from reuse: when multiple libraries call the same underlying functions, proofs about those shared components carry over. In experiments with shared proof workspaces, the same verification tasks required 17% fewer tokens — savings that compound as coverage expands. On 36 benchmark tasks, Claude Opus 5.5 completed the work using approximately 40% fewer tokens than Opus 5, extending how far the approach can reach before compute costs become prohibitive.

Anthropic has publicly released proofs for 25 of the 123 libraries, covering 60 entry points, available for OSS maintainers to download and reuse. The long-term scalability argument resembles how Mathlib works in mathematics: proofs build on a shared, cumulative verified foundation, and each new proof that enters the commons reduces the marginal cost of verifying the next adjacent component.

The Defensive Case Is Urgent — and the Attack Side Is Already Faster

The timing of this research is not incidental. One day before Anthropic published, Microsoft disclosed that Storm-0940, a threat actor assessed to be aligned with Chinese state interests, had used an AI agentic framework called ARTEX to automate intrusion operations against more than 2,250 tenants. In multiple successful cases, attackers moved from initial access to cloud-level privilege in under three hours.

Also on October 21, the PHP project released patches for two critical vulnerabilities — CVE-2026-109618 and CVE-2026-109619, each carrying a CVSS score of 9.2 — discovered by Wiz Research, Calif, and OpenAI using AI-assisted analysis with Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol. The flaws affected PHP versions going back to 5.4, meaning they had persisted, undetected, for over a decade. Roughly 70 percent of web servers run PHP. Matthew Prince, Cloudflare's CEO, reported observing millions of exploitation attempts across Cloudflare's network within hours of the patch announcement.

The PHP2Shell case illustrates the asymmetry clearly: AI is already finding decade-old flaws in widely deployed software, and attackers are moving to exploit them within hours of disclosure.

Anthropic's Cyber Mission, launched October 8 with eleven founding partners, explicitly acknowledged this dynamic. Jason Clinton, Anthropic's deputy chief information security officer, called for security leaders to seek board-level support for baseline defenses immediately, estimating conditions will worsen for roughly 18 months before improving.

What the Approach Does Not Yet Solve

Formal verification at this scale remains constrained in significant ways. The technique currently requires Theorem's formal semantic models for the target architecture and operating environment — limiting coverage to Linux processes on RISC-V. Extending to other platforms requires new models, which are non-trivial to build.

Bug confirmation and patching remains a human-mediated process. For critical infrastructure — power grids, water-treatment systems, industrial equipment — deploying fixes after a bug is confirmed is operationally complex and sometimes impractical in ways that software patches on consumer systems are not.

All figures published are company-reported: proof-line counts, token-savings estimates, benchmark comparisons. Independent evaluation of both the proof validity and the claimed efficiency gains has not yet been published, and should be considered necessary before these results inform industry-wide security standards.

The most significant open question is whether proof reuse scales fast enough to make the per-library cost fall as the commons grows. If it does, assembly-level AI-assisted verification could become standard CI tooling for high-value open-source projects. If the cost curve does not bend, the technique remains compelling for critical targets but too expensive for broad OSS adoption — a useful specialized capability rather than the foundation of a new security regime.