Anthropic and Theorem: Claude proves 239 open-source entry points crash-free in Rocq

Anthropic's Frontier Red Team and the verification startup Theorem say Claude has written machine-checked proofs that 239 entry points in 123 open-source libraries never crash, never trigger a memory-safety error and never fail an assertion, for any input up to 64 MB. The work, published on 22 October 2026, took "a few weeks", turned up hundreds of bugs on the way, and is presented as evidence that formal verification, long reserved for avionics and kernels, is becoming something a language model can do at scale. The claims are the authors' own, and they come with limits that matter as much as the headline.

Key points

• Claude proved no-crash properties for 239 entry points across 123 open-source libraries, mostly taken from Google's OSS-Fuzz project, according to Anthropic.
• The proofs hold for every input up to 64 MB, for single-threaded static RISC-V binaries linked against musl libc and running on Linux, and are checked by the Rocq proof checker.
• A typical proof is about 600,000 lines of Rocq, the total is about 180 million lines, and the median binary has about 18,000 RISC-V instructions.
• Hundreds of bugs surfaced during the attempts, including a rediscovery of CVE-2026-56132 in libexpat; the public GitHub release covers a subset, 60 entry points in 25 libraries.
• The authors stress that "formally verified" is not "bug-free": proofs are only as good as the specification and the machine model behind them.

What happened

The post, written by Anthropic's Frontier Red Team with Theorem (theorem.dev), describes a pipeline built around fuzz tests. A fuzz test is a function where any crash counts as a bug. For each one, the team compiled the library to a RISC-V executable and combined three things into a formal specification: the binary, Theorem's formal model of RISC-V and Linux processes, and the statement "this never crashes". Claude then wrote the proof, and the Rocq proof checker, a long-established piece of software, verified it. When Claude found a real bug, it patched the code, regenerated the specification and proved the patched version.

The scope is the first thing to read carefully. The proof covers every input up to 64 MB, and every Linux response and memory layout the model allows. That is a very different guarantee from a fuzzer, which mutates inputs and, according to the authors, typically stays near 1 MB. The cost of that guarantee is size: a typical proof is about 600,000 lines, the total is about 180 million lines of Rocq, and a proof can take hundreds of millions of tokens.

Because the checker verifies every step, a developer does not have to trust Claude. What they must trust is the RISC-V and Linux semantic models, the exact theorem statement, the Rocq checker, and beneath that the hardware, the operating system and the OCaml compiler Rocq itself runs on.

Background

Formal verification means translating code into a mathematical model and proving it obeys stated rules. A failed proof points at a likely bug; a finished one is a guarantee within the model. The post uses the seL4 microkernel as the benchmark for cost: about two person-years to implement and about 20 person-years to verify. Until now the technique has mostly protected mission-critical systems such as Airbus avionics code.

Two trends meet in the post. The authors note that over 1,000 Linux kernel vulnerabilities were disclosed recently and that language models are getting better at finding bugs and chaining them into exploits. Their argument is that if models can attack code at scale, the same models should be used to prove code safe at scale. Anthropic recently published a related piece of work, in which Claude was used to cut OpenSSH's pre-login attack surface; we covered it in Anthropic used Claude to cut OpenSSH's pre-login attack surface.

The numbers

Two views matter: how big the study is, and how much of it the public can check today. The GitHub repository for the proofs, theorem-labs/oss-verify-proofs, describes itself as theorem statements about OSS-Fuzz fuzz targets compiled as RISC-V binaries, with machine-checked Rocq proofs. It says that release contains proofs for 60 entry points in 25 libraries (simdjson, openssl, zstd and leptonica among them). The post withholds proofs that would reveal unpatched bugs.

Study total239

Public repository60

Entry points proved: Anthropic's study vs the public repository (entry points)

	entry points
Study total	239
Public repository	60

Source: Anthropic research post (22 Oct 2026); theorem-labs/oss-verify-proofs README

The repository also lists a much larger backlog: 20,164 statements across 2,148 harnesses from 427 OSS-Fuzz projects, of which the README counts 138 proved, none known false, and 19,797 still open. That illustrates the gap between "can be done" and "has been done": the pipeline works on a sample, and most of the catalogue is still unproven.

Efficiency numbers in the post point the same way. On 36 small verification tasks taken from OSS-Fuzz code, Opus 5.5 proved half of them using about 40% fewer tokens than Opus 5, the authors report. When agents could copy each other's proofs from a shared workspace, they used 17% fewer tokens than agents working alone, and some succeeded where solo attempts failed; working alone, agents could not complete two of the 36 proofs. Teams also copied finished proofs between programs (the post names libcups, freerdp and libzmq), because much of each proof covers code every program shares, such as C runtime setup.

What the proofs found

The proof attempts surfaced hundreds of bugs. The post lists several examples:

• a counter underflow in a decompressor that led to an out-of-bounds write, triggered only by inputs of roughly 20 MB with one rare layout;
• an out-of-bounds read in an image decoder that needed a 64 MB input and more than 2 GB of memory;
• an out-of-bounds read that needed a particular sequence of calls across two handles to the same file;
• a rediscovery of CVE-2026-56132 in libexpat, triggered by deeply nested input;
• a logic bug in which a file-restriction feature was not always enforced, which never crashes at all.

The authors say fuzzers are unlikely to find many of these, since the inputs are huge or the call sequences unusual. Fuzz tests also often encode higher-level properties such as round-tripping or equivalence to a reference implementation, so proving that a test never fails can prove those too. For cpp-httplib, Claude had to prove at machine-code level that libc++'s red-black tree stays logarithmically bounded in depth, ruling out a stack overflow in recursive destruction.

Other case studies in the post: a formal specification of RFC 1950 (zlib) and a proof, at the x86 binary level, that the Linux kernel's zlib implementation meets it, repeated for about half a dozen other widely used libraries with only minor, unexploitable corner-case bugs found; and a Python-subset interpreter in Rust, proved with Verus against CPython semantics from an academic paper, whose behaviour matched CPython in 99.95% of 1.7 million random programs. On a widely used PDF reader, the authors say they found as many security bugs in one week as are typically reported in a year, and that simple security-property proofs exposed a logic bug that had been latent for over a decade.

What it means

For maintainers. The most immediate effect is on bug-finding. Even where a proof was never finished, the attempt surfaced bugs, so the process doubles as a very deep audit. Theorem offers to run the pipeline for other open-source projects and has published a Claude skill for verifying your own code.

For the industry. The authors' claim is that verification will become as routine as fuzzing for most production software. Their logic is that dependencies follow a power law: verifying a small set of shared libraries could make a large share of software provable. Theorem's stated roadmap targets the Nix ecosystem, including glibc, OpenSSL and cURL. They compare the idea to Mathlib, the Lean mathematics library, which has nearly 300,000 theorems from over 700 contributors.

For security teams. A proof removes a class of failure within its model, not all risk. Expect "formally verified" to appear in marketing; the questions to ask are what the property is and what the model assumes.

What we don't know yet

• How the guarantees transfer to real deployments. The proofs cover single-threaded static RISC-V binaries with musl; production systems mostly run x86 or ARM, often with dynamically linked glibc, and the authors say closing this gap needs accurate models of the deployed systems.
• How complete the coverage is. Not every entry point was verified, AddressSanitizer does not catch every memory-safety bug, and callers can still misuse a library and corrupt memory on their side.
• Whether the semantics are right. Claude generated x86 and other instruction-set semantics itself; the process found hundreds of errors in official reference documentation and a smaller number of hardware bugs, but the authors cannot guarantee the semantics are perfect. The repository calls its Linux process model "best effort and not complete".
• Independent replication. Everything here comes from the authors and their repository; we found no independent evaluation yet.
• Termination. The repository says no proof in this release rules out a run that never ends.

What to watch next

Watch whether independent researchers check the published proofs and semantics, and whether maintainers adopt the pipeline on their own projects. Watch Theorem's work on the Nix ecosystem and the libraries it names. And watch how the authors handle reward hacking, which they flag themselves: Claude could make a theorem provable by rewriting a program so that it never crashes, so they penalised patches, gave extra credit for proving which inputs a patch changes, and logged and audited every patch.

Sources

• Anthropic Frontier Red Team with Theorem: LLMs are making formal software verification feasible at a much larger scale (primary source)
• theorem-labs/oss-verify-proofs on GitHub
• Theorem
• audiotale.net: Anthropic used Claude to cut OpenSSH's pre-login attack surface