Finding a vulnerability in Starknet’s zero-knowledge proof system with our AI auditor

We built an AI auditor to continuously hunt for soundness bugs in OpenVM, as one layer of a security approach encompassing human review, formal verification, and continuous AI auditing. It works well enough on our own code that we decided to test it on StarkWare's stwo-cairo, the production proof system securing Starknet, a blockchain system with $400M in user assets.

Running autonomously from a general prompt, our auditor found a soundness vulnerability, the most severe class of issue in a proof system, and confirmed it by forging a proof of an invalid execution accepted by the unmodified verifiers. Fortunately, because proving on Starknet is permissioned, exploiting the vulnerability would have required control or compromise of the authorized prover, meaning no user assets were at risk. We reported the vulnerability to StarkWare with a proof of concept on June 5, 2026, and a fix was shipped to Starknet mainnet shortly afterwards.

This vulnerability had been present since stwo-cairo was open-sourced in 2024, surviving an external audit and a formal verification that explicitly excluded the vulnerable component from its scope. That a critical bug could persist through that much scrutiny, then be uncovered by an autonomous agent, points to where defensive security is heading: formal methods and AI working together, applied broadly enough to cover all components. Read on for more on the finding itself.

Background: Starknet and why security matters for ZK proofs

Starknet is a zero-knowledge (ZK) rollup on Ethereum: it runs transactions on its own chain and settles them on Ethereum, keeping fees low by not re-executing everything on Ethereum directly. People use it to send payments, issue assets, and trade, and as of early July 2026, it holds roughly $400M in user assets.

Those assets are secured by Starknet’s zero-knowledge proof system, stwo. Starknet proves validity of its transactions to Ethereum by generating a zero-knowledge proof that all the rules of the network were followed, and that proof is the sole basis for guaranteeing that user assets are not stolen. To reduce the attack surface, proving on Starknet is permissioned today, meaning a vulnerability in the proof system can only be exploited by a malicious or compromised prover. In a permissionless setting, such a vulnerability would put all assets secured by that permissionless deployment at risk.

As a result, the security of stwo and its implementation in the stwo-cairo system is paramount and was the focus of extensive security work by StarkWare. This included a security audit by zkSecurity in July 2025 prior to production deployment in November 2025 and formal verification of some of the stwo circuits in Lean in June 2026 to further enhance security. Together, these make stwo-cairo one of the most scrutinized proof systems in production.

Discovering the Vulnerability

In June 2026, we pointed our AI auditor at stwo-cairo, StarkWare's prover and verifier for the Cairo virtual machine. The auditor is a multi-agent system that generates candidate vulnerabilities, discards false positives, and validates the rest with proof-of-concept exploits.

Each agent works in an isolated sandbox with direct access to the target codebase plus our proprietary database of ZK security issues from internal OpenVM reviews. That corpus pairs real findings with the false positives the auditor has previously flagged, which is critical to avoid producing a flood of incorrect reports.

Running fully autonomously, the auditor identified a soundness vulnerability in the global LogUp check, then confirmed it by forging a proof that the Rust and recursive Cairo verifiers accept. This vulnerability was found from a general prompt to investigate stwo-cairo, with no special direction towards any particular system component.

Like most modern ZK systems, stwo-cairo uses the LogUp lookup argument based on logarithmic derivatives. Implementing LogUp correctly requires constraining claimed_sum, the sum of each circuit component's lookup terms, and checking that claimed_sum values sum to zero across components. This global summation, called lookup_sum, should be computed by the verifier, which rejects any proof where it is nonzero.

Our AI auditor found that one of the claimed_sum terms, memory_id_to_big.claimed_sum, that the verifier folds into lookup_sum is treated as a trusted input: it is never absorbed into the prover's Fiat-Shamir transcript, so nothing binds the prover to a particular value. A malicious prover can therefore choose it freely to drive an invalid lookup_sum to 0, forging a proof of an incorrect statement. This vulnerability was present in both verifiers.

For a proof of concept, our AI auditor modified the prover to supply a maliciously crafted memory_id_to_big.claimed_sum value balancing the lookup_sum for a Cairo program claiming a field multiplication with incorrect output. The resulting adversarial prover was able to forge proofs of incorrect statements that the unmodified verifiers accept.

Impact and Remediation

This vulnerability compromised soundness of both the Rust and recursive verifiers for stwo-cairo, the most severe class of vulnerability in a zero-knowledge proof system. This allowed for forged proofs of invalid state transitions for Cairo, which would affect any downstream applications relying on stwo-cairo in a permissionless way.

Fortunately, proving on Starknet is permissioned and no user assets were affected, as only a malicious or compromised prover could exploit this vulnerability. We reported the finding to StarkWare on June 5, 2026 with a proof of concept and suggested patch. The StarkWare team deployed a fix to mainnet shortly thereafter and awarded a generous bounty through its bug bounty program. We thank StarkWare for their prompt response and remediation.

Conclusion

We are witnessing a monumental shift in the offensive security landscape. AI is compressing the time and expertise needed to find vulnerabilities, write exploits, and run attacks, allowing adversaries previously limited by cost or skill to now operate at scale. The systems most exposed are the ones where a single exploit has real financial consequences.

Defending them will take more than finding bugs faster than attackers do. It means shrinking the surface area exposed to vulnerabilities by pushing formal verification to cover more of each system, and using AI auditing to watch the parts it hasn't reached. That is the direction we're building toward, and we'll have more to share on it soon.