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.

Despite a security audit by zkSecurity prior to production deployment and formal verification of some of the stwo circuits in Lean to further enhance security, a refactor in June 2026 introduced the vulnerability, and our AI auditor caught it shortly afterward. That a critical bug can be introduced inadvertently even with such a rigorous security posture points to where defensive security is heading: formal methods and AI working together, applied broadly and consistently enough to ensure continuous coverage. 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 the 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, a soundness vulnerability like what we discovered 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.

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.

Correction to Prior Post (August 2026)

An earlier version of this post stated that this vulnerability had been present since stwo-cairo was open-sourced and had survived zkSecurity's external audit. That characterization was incorrect. We reviewed the commit zkSecurity audited (aef7d09, July 2025) and confirmed that at that commit, memory_id_to_big.claimed_sum was absorbed into the Fiat-Shamir transcript and bound to the trace by both a length-consistency check and per-component boundary constraints. The vulnerable code path did not exist in the version zkSecurity audited, and the regression was introduced roughly eleven months later in commit 819c080f (June, 2026), in which a refactor flattened the verifier's interaction claims and dropped the per-component length check zkSecurity's audit had relied on. Our AI auditor caught it shortly after it landed. We've corrected the affected sentence above and thank zkSecurity for flagging the error. The finding itself, a real soundness bug confirmed and fixed by StarkWare, remains unchanged.