# Aztec Says an Attacker Could Forge Valid Proofs on Its Live Privacy Network

Core contributors found the flaw on 27 July through internal artificial-intelligence-assisted auditing, cannot rule out prior exploitation, and have deferred the fix to the next version of the protocol.

- Published: 2026-09-10T05:53:21.186Z
- Canonical: https://polylog.news/crypto/2026-09-10/aztec-says-an-attacker-could-forge-valid-proofs-on-its-live
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [Aztec Network](https://aztec.network/blog/alpha-v5-proving-system-vulnerability), [Aztec Network (Alpha V5)](https://aztec.network/alpha-v5), [Aztec Network (Apps)](https://aztec.network/blog/dark-forest-aztec-game-goes-live)

Aztec, the privacy-focused Ethereum layer-2 network, has [disclosed a critical vulnerability in the proving system](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) underpinning its live Alpha V5 network. According to the project, an attacker may be able to construct a zero-knowledge proof (a cryptographic argument that a computation was performed correctly, without revealing its inputs) that passes verification for a transaction the network is supposed to reject. If the network accepted such a proof, the resulting state transition would fall outside the rules V5 is designed to enforce, placing funds, applications and contract state at risk.

Core contributors say they identified the defect on 27 July 2026 through internal auditing assisted by artificial intelligence, after internal and external human audits had already been completed. They also state plainly that they cannot determine whether anyone exploited the flaw before the finding. Reviewers have not identified other high-severity or critical issues in V5 Alpha, and the fix is planned for V6, expected later in 2026.

The disclosure follows the same pattern Aztec used earlier this year, when it withheld details of a critical V4 proving bug until a governance upgrade moved users off the affected version. That sequencing is deliberate. A soundness defect cannot be quietly patched around, because publishing it before users can exit would give any attacker the technical detail needed to replicate the exploit.

The class of failure matters more than this one network. Most rollups treat validator re-execution as the backstop that catches bad state. Re-execution catches an invalid transaction. It does not catch a valid-looking proof of an invalid transaction, because the proof itself is the thing being trusted. Aztec's [Alpha V5 release](https://aztec.network/alpha-v5) and the [applications now deployed on it](https://aztec.network/blog/dark-forest-aztec-game-goes-live) run on software the team itself labels experimental, an honest framing that most production zero-knowledge systems do not offer.

## What this means

Proof soundness is the single trust assumption a zero-knowledge rollup cannot delegate. When it breaks, the users exposed are those with assets sitting inside the rollup, and the only remedy is exiting before disclosure or waiting for an upgrade. For the wider layer-2 sector, the finding shifts the security question from "is the contract audited" to "who else can verify the prover," which favours networks with proof-system diversity, working escape hatches and published upgrade timelines, and penalises those whose security rests on a single unreviewed proving stack.

## What to watch

- Whether the V6 upgrade ships on the timeline Aztec has stated, and whether the project publishes the technical detail of the V5 flaw once users can move, since a delayed disclosure keeps other zero-knowledge teams from checking for the same defect.
- Whether other zero-knowledge rollups disclose proving-system findings from artificial-intelligence-assisted review, which would indicate the tooling is now surfacing a backlog rather than catching isolated mistakes.
- Whether value secured on privacy-focused layer-2 networks falls after the disclosure, which would show that users price proving risk differently from smart-contract risk.