# Aztec discloses a critical flaw in its Alpha V5 proving system that could let a forged proof pass verification

Contributors found the bug through internal AI-assisted auditing on July 27. They say chain history cannot show whether anyone exploited it. It is the second critical proving-system flaw in consecutive versions of the privacy network.

- Published: 2026-10-06T05:32:21.128Z
- Canonical: https://polylog.news/crypto/2026-10-06/aztec-discloses-a-critical-flaw-in-its-alpha-v5-proving-syst
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [Aztec Network](https://aztec.network/blog/alpha-v5-proving-system-vulnerability), [Aztec Network](https://aztec.network/alpha-v5), [The Defiant](https://thedefiant.io/news/defi/aztec-v4-withdraw-june-25-v5-upgrade-security-vulnerability), [Aztec Network](https://aztec.network/blog/aztec-network-raises-total-bug-bounty-to-2-million)

Aztec's core contributors have [disclosed a critical vulnerability](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) in the proving system of [Alpha V5](https://aztec.network/alpha-v5), the current version of the Ethereum layer-2 network built for private smart contracts. They say an attacker may be able to construct a proof that passes verification for a transaction the network should reject. If the network accepted such a transaction, it could produce a change in state outside the rules V5 is meant to enforce.

That class of bug breaks the guarantee a zero-knowledge (ZK) system exists to provide: a valid proof means a valid computation. Aztec says it found the flaw on July 27 through internal AI-assisted auditing. It also says it cannot tell whether anyone used the flaw before then. In its words, the affected system lacks the information needed to distinguish ordinary accepted transactions from those accepted through the flawed proving path. Historical chain activity therefore cannot establish whether exploitation occurred or measure its impact.

The privacy design explains this gap. On a transparent chain, investigators can re-execute history and look for impossible balances. On a network where users generate proofs of private execution and the chain checks only the proof, a forged proof leaves no different trace from an honest one.

Aztec has told teams planning V5 deployments to pause until contributors publish further guidance. Teams with live contracts should review how to limit user exposure, isolate affected functions and, if needed, move users to fresh deployments. The fix will come in V6, which will include circuit updates so that the network rejects proofs tied to the affected proving system. Aztec says reviewers have found no other high-severity or critical V5 issues. It also says internal and external human audits are complete, and that AI-assisted auditing continues.

Aztec's track record adds to the picture. Earlier this year Aztec [told Alpha V4 users to withdraw funds before June 25](https://thedefiant.io/news/defi/aztec-v4-withdraw-june-25-v5-upgrade-security-vulnerability), when the V5 governance vote would publicly disclose a critical proving-system vulnerability in V4. The project has raised its total [bug bounty to $2 million](https://aztec.network/blog/aztec-network-raises-total-bug-bounty-to-2-million). Two consecutive versions with soundness flaws show that the proving layer, not only the application contracts, is a major unresolved risk for privacy rollups.

## What this means

The mechanism is a soundness failure that ordinary monitoring cannot detect. Validators and observers who re-execute transactions see only proofs, so a forged one looks valid. The parties exposed are users of Aztec applications, teams building on V5, and every institution being told that confidential execution is ready for serious money. The closest precedent is Zcash's 2018 counterfeiting flaw in its original proving parameters. Zcash fixed it quietly in the Sapling upgrade and disclosed it months later. It also could not prove from the chain alone that no counterfeit coins had been created. It bounded the risk afterward by tracking how much value left the old pool. The common view treats AI-assisted auditing as purely defensive. Here it found the bug, but the same tools are available to attackers looking for the next one. The desk's forward read is that Aztec will keep alpha status, deposit limits and migration-based upgrades through the V6 release later this year. Institutional deployments on privacy rollups will wait for at least one version with no critical disclosure. That depends on V6 shipping with independent audits of the new circuits. A further critical disclosure in V6 would extend the delay into 2027. A V6 that adds a second, independent proof check before accepting state changes would shorten it.

## What to watch

- Whether V6 adds a second independent proving or verification path rather than only patching the affected circuits. Diversity is the structural defense against this class of bug.
- Whether Aztec publishes a method to bound possible losses, similar to Zcash's tracking of value leaving its old pool. Users currently have no way to know whether supply was inflated.
- Whether other privacy and ZK-rollup teams report proving-system flaws found by AI-assisted review. Such reports would show that the method is uncovering a backlog of hidden defects across the sector.