Claude cranks out 180 million lines of proof, uncovering hundreds of bugs

Claude writes 180 million lines of proof, uncovers hundreds of bugs

Claude spent several weeks, for239 test entry points across 123 open‑source software libraries, writing about 180 million lines of proofs to verify software security.

During the proof‑writing process, Claude also happened to discoverhundreds of bugs.

According to Anthropic, some of these bugsevaded tens of trillions of tests and remained hidden for many years.

Anthropic says, this is the first time AI has been used at the assembly level to formally verify real production software at scale.

What used to take a top‑expert team several years to complete is now handled by Claude on an assembly line.

◽Work that used to take experts 20 years, Claude finishes the proof in weeks

First, let’s talk about how the software community usually finds bugs.

The most common method is called fuzz testing: feeding massive amounts of random data into a program to see which input crashes it, like sending a crowd of people to run around a building to see where it collapses.

Google’s OSS-Fuzz platform continuously fuzzes thousands of open‑source projects.

This approach works well, but it has a fatal flaw:the input is endless.

Today you feed a million inputs without incident, and tomorrow the one‑million‑and‑first input could still cause a problem.

It can only ever say “none of the inputs I tried caused an issue,” but it cannot claim “all possible inputs are safe.”

Another approach is calledformal verification.

It’s still the same building; you don’t just jump in or rely on luck. Instead, you ask a structural engineer to calculate from the blueprints: how thick each beam needs to be, how much load it can bear, and whether it will crush the adjacent columns.

After calculating each beam one by one, the final statement is:Build according to these plans, and the building won’t collapse.

This “taking the blueprint and calculating step by step” process is formal verification.

When applied to software, the verification task is to express “this program never triggers such bugs for any data” as a mathematical proposition and then prove it rigorously step by step.

Once the proof holds, you no longer need to test each case.Because it covers all possibilities, not a sampled result.

The problem is, it’s too expensive.

Anthropic gave an example: the seL4 operating system kernel,took 2 person‑years to write the code, but formal verification took 20 person‑years.

So over the past few decades, this approach has basically only been used for code where a failure would be fatal, like Airbus avionics.

This time, Claude took a different approach.

You don’t need to come up with the problem yourself. Developers write test harnesses on OSS-Fuzz, with the standard that “if the program crashes, it indicates a bug”; “this harness should not crash on any input” is a ready-made problem.

Don’t count the blueprint, count the building that’s actually constructed. Code must go through a compiler, which rewrites and optimizes it, so the blueprint and the actual artifact aren’t exactly the same.

Therefore the team compiles the libraries and tests into RISC-V (a chip instruction set) machine code, and then uses Theorem’s chip and system models to generate problems.

The rest is left to Claude to write the proof, and after finishing it is checked by Rocq line by line, any single mistake will not pass.

The scale is like this: a typical proof contains 600,000 lines, corresponding to only about 18,000 machine instructions in the program.

123 libraries and 239 entry points combined,about 180 million lines.

With so many proofs, humans simply can’t review them all, but that’s fine because no human review is needed.

Developers only need to trust three things: the formal model of the chip and Linux, the way the propositions are written, and the Coq checker.

The remaining 180 million lines are all vetted by machines.

But here’s the problem: what if, while proving, you reach a point where you can’t continue?

◽The spot where the proof gets stuck often hides a bug

The answer is simple: The places where the proof fails often hide the real bug.

Some programs themselves have vulnerabilities, so the proposition “won’t error” is fundamentally false, and Claude naturally can’t prove it.

The team simply lets Claude handle it: when it discovers a bug, it patches itself, then regenerates the proposition and continues the proof.

Thus, Claude has uncovered hundreds of bugs.

Moreover, many of them are fuzz tests that are almost impossible to hit.

The data that fuzz testing tools inject into a program usually does not exceed 1MB.

The scope proven by Claude, however, covered 64MB.

So, the following bugs were uncovered:

A decompressor’s counter underflows, causing an out‑of‑bounds memory write,but it only triggers when the input is around 20 MB and the structure is particularly tricky.

An image decoder’s out‑of‑bounds read,requires 64 MB of input plus over 2 GB of memory.

Claude alsorediscovers the known libexpat vulnerability CVE-2026-56132, which requires deeply nested input to trigger.

Some bugs don’t even cause the program to crash.

When proving the memory safety of a library, Claude noticed it has a “restrict which files the application can load” feature,which doesn’t work every time.

Of course, letting AI modify code itself also carries the risk of it exploiting loopholes.

In theory, Claude could change the program to “do nothing,” which would never fail and would easily pass verification.

The team’s response is:Deduct points for each patch applied; only award points if it can be shown the patch affects only a tiny fraction of inputs. All patches are documented and audited one by one.

Besides these 123 libraries, Anthropic also conducted several other experiments using the same approach.

One of them is validating a commonly used PDF reader, a security bug found in a week, equivalent to the number of reports this software typically receives in a year.

Another one, in a widely used critical application, uncovered a logical bug that had been lurking for over ten years and had never been discovered before.

◽Claude makes proofs cheaper, but a proof doesn’t mean zero bugs

180 million lines of proof—just hearing that sounds expensive.

Anthropic also admits that a single proof can consume over a hundred million tokens, which is currently the biggest bottleneck.

However, the accounts are looking better.

The team built 36 small verification tasks using real OSS-Fuzz code,and Opus 5.5 completed half of them, using about 40% fewer tokens than Opus 5.

And it even proves you can “copy homework.”

Proofs for different programs contain a lot of duplicated parts, such as C runtime and memory checker initialization. By letting multiple agents share a workspace and reuse proofs,the token usage can be reduced by another 17%, some tasks that couldn’t be proved individually are now provable.

Now, Theorem has open-sourced part of its proofs and released a Claude skill to help developers start verifying their code.

It also opens up OSS Verify: qualifying open‑source projects can run this pipeline for free.

But, “verified” doesn’t mean “bug‑free.”

Anthropic even dedicated a section to this point in the original text.

This set of proofs has several clear boundaries:

It demonstrates that it runs on RISC‑V chips and is packaged in a specific way. Most phones and computers, however, use ARM and x86 chips. It only covers some entry points and does not represent the entire library. It only guarantees that the program won’t crash and that memory won’t overflow,but it does not guarantee that the computed results are correct.

But this is already a huge step.

In recent years, AI’s ability to find vulnerabilities has become increasingly strong. The latest Linux kernel disclosure alone revealed over a thousand bugs.

Finding bugs has become cheaper, and attacks have followed suit. Defenders who rely solely on discovering and patching one by one are falling further behind.

This time, Claude offered another possibility:

Not just finding bugs, but directly proving that there are no bugs on this path under given conditions.

Anthropic wrote at the end of the article that formal verification will soon become a standard for almost all production software, just like fuzz testing is today.

Whether it becomes reality depends on how many open-source projects actually line up to adopt it.

But at least this time, the defenders have gotten a weapon that can be scaled.