🔍 Read the full analysis: A Closer Look At Anthropic’s Fuzz Testing And Proofs on ThorstenMeyerAI.com
Get smart everyday buys delivered free with Prime
- Fast, free delivery on millions of items
- Prime Video, Amazon Music and more included
- Member-only deals all year
TL;DR
Anthropic’s Frontier Red Team and collaborator Theorem say Claude produced Rocq-checked proofs of a no-crash property for 239 fuzz-test entry points across 123 open-source libraries. The work also found bugs that fuzzing had missed, but the proofs apply only to specified RISC-V builds and conditions—not every version or use of the libraries.
Anthropic’s Frontier Red Team and its collaborator Theorem reported October 22 that Claude had produced machine-checked security proofs for 239 fuzz-test entry points across 123 open-source libraries. The proofs establish a defined no-crash property for specific compiled programs, and the team said the verification effort found hundreds of bugs, including issues that years of fuzzing had not uncovered.
The reported property is bounded and specific: for each entry point, the compiled RISC-V program does not crash on any input under 64 MB, under the team’s stated assumptions. The checks include AddressSanitizer memory errors and failed assertions. This does not establish that a library is free of every vulnerability or behaves correctly in every setting.
The process starts with an existing fuzz test, which serves as the specification. The libraries and tests are compiled into instrumented RISC-V executables, and Claude writes proofs in Rocq, a proof-assistant language. Rocq’s checker verifies whether each proof follows from its specification and formal models. When a proof attempt exposes a failure, the team says it can point to a potential bug; Claude can then patch the code and attempt a new proof against the regenerated specification.
Anthropic and Theorem reported producing about 180 million lines of proof over a few weeks. A typical proof was about 600,000 lines, covering a binary with a median length of 18,000 RISC-V instructions. The report says the proofs that did not require patches, some previously unpublished trusted components, and specifications for fuzz tests the team could not prove are being published.
Infographic 01 · From test to proof
Existing fuzz tests became specifications. Claude proved them.
Over a few weeks, Claude proved at the machine-code level that hundreds of real fuzz entry points can no longer crash, after patching the bugs it found.
The pipeline
From an existing test to a checked proof
- Compile. The library and its existing fuzz test become a RISC-V executable, instrumented with AddressSanitizer.
- Specify. Theorem’s RISC-V and Linux process semantics plus the no-crash property mechanically yield the specification.
- Prove. Claude writes the proof in Rocq. A failed attempt points at a possible bug; Claude patches it and proves the new spec.
- Check. The Rocq proof checker verifies the proof. Virtually none of the proof needs human review.
Fuzzing vs. proof
Same entry point, different guarantee
| Fuzzing | Proof | |
|---|---|---|
| Inputs | Fuzzing: Generated samples, typically capped at 1 MB | Proof: Every input under 64 MB |
| Paths | Fuzzing: Guided by code coverage, no guarantee | Proof: Every path reachable from the entry point |
| Result | Fuzzing: Bugs found so far | Proof: No crash left to find on the modelled system |
Typical proof: about 600,000 lines for a binary with a median length of 18,000 RISC-V instructions.
“If Claude can prove this spec, the fuzz test on RISC-V becomes superfluous.”Anthropic, 22 Oct 2026
Source: Anthropic, “LLMs are making formal software verification feasible at a much larger scale” (22 Oct 2026).
Powered by Thorsten Meyer AI
Where Machine-Checked Proofs Find Bugs
The results show how formal verification can complement testing: a fuzzer samples inputs and execution paths, while a successful proof addresses every path reachable under its model. That difference can expose edge cases that random or mutated inputs are unlikely to reach. The team described finding hundreds of bugs, including a decompressor counter underflow leading to an out-of-bounds write on an input of around 20 MB with a rare layout, and an image-decoder out-of-bounds read requiring a 64 MB input and more than 2 GB of memory.
Other reported cases involved a particular sequence of calls across two handles to the same file, deeply nested input associated with a rediscovery of CVE-2026-56132 in libexpat, and a logic error in a feature intended to restrict which files an application could load. The last example matters because a property can fail without causing a crash: a no-crash proof based on a test can cover only what that test checks.
The work’s practical importance is its possible effect on verification costs, not a claim that software can now be certified automatically in general. Anthropic argues that language models can help generate proofs while a small checker verifies them. But the source also says some proofs require hundreds of millions of tokens, making computational cost a major constraint. The reported scale is a research result, not evidence that all projects can use the technique cheaply.
As an affiliate, we earn on qualifying purchases.
From Fuzz Tests to Formal Specifications
Fuzzing is widely used to find software faults by feeding a program many random or modified inputs and watching for crashes or other failures. Its results depend on the inputs and execution paths reached; a run without a crash does not prove that every possible input is safe. Anthropic and Theorem’s approach turns the existing fuzz-test behavior into a property to prove about a compiled program, rather than treating a large number of successful test runs as proof.
Formal verification can offer stronger guarantees within a carefully defined model, but it has traditionally demanded substantial specialist effort. Anthropic cites the seL4 microkernel as an example of that burden, saying its construction took two person-years and its verification 20 person-years. In this project, the team relied on formal models of RISC-V instructions and Linux processes, with Rocq checking the generated proofs.
The scope is narrower than the phrase “formally verified” may suggest. The reported work covers single-threaded, static RISC-V binaries linked against musl. It does not directly establish the same property for the x86 or ARM builds linked against glibc that are more commonly used. The proof’s force also depends on the specification and trusted components, including the formal models and checker.
““discovered hundreds of bugs.””
— Anthropic, in the report described by Thorsten Meyer
As an affiliate, we earn on qualifying purchases.
Limits of the Verified Builds
The result does not show that the libraries are bug-free. It shows that specified fuzz-test entry points satisfy a particular no-crash property in one modeled build configuration, for inputs below 64 MB and under stated assumptions. The source does not establish that the proofs cover concurrency, other architectures, different library configurations, or every security property users may care about.
The precise total and classification of bugs are also not fully detailed in the supplied account. It says “hundreds” were found and describes several examples, but does not give a complete list or state how many were fixed, independently confirmed, or disclosed to maintainers. The source says some proof attempts could not be completed and that their specifications are being published, but does not identify all such cases.
Cost and reproducibility remain open questions. The account says proofs can consume hundreds of millions of tokens and that newer models and shared proofs can reduce the burden, but supplies no full cost comparison or general estimate for applying the method to another codebase. The trusted base—including formal models, the theorem statements, Rocq, and supporting software—also remains part of what users must evaluate.
As an affiliate, we earn on qualifying purchases.
Published Proofs and Further Validation
Anthropic says it is publishing the proofs that required no patching, trusted components that were not already public, and specifications for tests it could not prove. Those materials will let researchers and maintainers inspect the scope of the claims, check the proof artifacts, and see where the pipeline stopped short.
The next practical questions are whether maintainers confirm and address the reported bugs, whether the approach can be applied to other build targets such as x86 and ARM, and how much computational effort it takes on additional projects. The supplied account does not give dates for those steps or describe a completed independent audit. For now, the reported work is a large demonstration of AI-assisted verification within a tightly bounded model—not a blanket security guarantee for the libraries.
As an affiliate, we earn on qualifying purchases.
Key Questions
What did Claude prove?
According to Anthropic and Theorem, Claude generated Rocq proofs that 239 fuzz-test entry points in 123 libraries would not crash for inputs under 64 MB in the specified compiled RISC-V programs, under stated assumptions. This is not proof that the libraries have no bugs.
How is this different from fuzz testing?
Fuzzing tries many inputs but cannot guarantee that every possible path has been tested. A successful formal proof covers every path reachable under the proof’s model and specification. The two methods can complement each other: fuzz tests supply the property, while the proof checks it across the modeled program.
What kinds of bugs did the effort find?
The report describes memory-safety issues, including an out-of-bounds write and reads, as well as a logic error involving a file restriction feature. It also says the effort rediscovered CVE-2026-56132 in libexpat. The source material does not provide a complete bug list or status for every report.
Do the proofs apply to software people commonly run?
Not directly to every build. The reported proofs cover single-threaded, static RISC-V binaries linked against musl. The source says they do not establish the same result for common x86 or ARM builds linked against glibc.
What remains uncertain?
The full bug count and resolution status, independent validation, general cost, and performance on other architectures are not established in the supplied account. The proofs also cover a defined no-crash property, not every possible security or correctness requirement.
Source: ThorstenMeyerAI.com
Halloween Picks
halloween
As an affiliate, we earn on qualifying purchases.
