Morning Edition · Sunday, August 30, 2026Published at 1:48 AM EDT · New York
Core contributors found the defect on July 27 through internal auditing assisted by artificial intelligence (AI), and say an attacker could construct a proof the network accepts for a transaction it should reject.

Aztec, the privacy-focused Ethereum layer-2 network, has disclosed a critical vulnerability in the proving system behind its Alpha V5 release. Core contributors identified the defect on July 27 during internal auditing assisted by AI tools. According to the disclosure, an attacker may be able to build a zero-knowledge proof that the network's verifier accepts for a transaction the rules should reject. Contributors advised users to treat funds, applications and contract state on Alpha V5 as exposed to a protocol-level failure until incident response finishes and network operators complete the required actions.
This is a soundness failure, not an ordinary smart-contract bug. A rollup that proves its state transitions replaces the work every node would otherwise redo. When the proof system itself accepts an invalid statement, the fallback most networks rely on, independent re-execution by validators, does not exist to catch it. That is the reason this class of defect keeps arriving through embargoed disclosure timed to an upgrade rather than through an on-chain incident.
This is not Aztec's first disclosure of this kind. In March, the team disclosed a critical flaw affecting the entire Alpha V4 proving system and told V4 users to withdraw funds before June 25. That date mattered because it was when the V5 governance proposal was set to move on-chain, a step that would force public disclosure of the older bugs under the project's transparency commitments. Two consecutive alpha releases have now carried a critical proving-system defect, and both were found by the people building the system rather than by an attacker.
The network is not idle infrastructure. Applications have been shipping on it, including a live on-chain game built around hidden state, the kind of use that only works when execution is private. Aztec's pitch, and the pitch of every confidential-execution project competing with it, rests on users believing the cryptography holds. Each disclosure of this kind moves the conversation about privacy chains from what they can hide to whether their verifiers can be fooled.
Part of a tracked trend
Proving-System Bugs Become a Distinct Rollup Risk
Soundness defects in zero-knowledge proving systems will keep surfacing as a risk class separate from smart-contract exploits, because validator re-execution — the fallback most rollups rely on — cannot catch them, forcing teams into embargoed disclosure timed to upgrades and pushing users toward proof-system diversity and escape hatches.
Start a discussion in Townsquare.
More from this edition
Aztec, which converts a self-found soundness defect into evidence that its internal review works, and the AI-assisted audit vendors and zero-knowledge competitors that can now sell proof-system review to every rollup holding user deposits.
The existence and severity of the V5 flaw rest almost entirely on Aztec's own disclosure, with no independent researcher having reproduced it and no technical detail published, so "an attacker may be able to" remains the project's own characterization rather than a verified exploit, and the March V4 disclosure shows the same pattern of embargoed detail timed to a governance vote.
An open-source-intelligence read of how likely this story is true with its real nuance, not a judgment of any outlet. It assesses the claim, weighing independent and adversarial reporting. How we label confidence.
What this means
Zero-knowledge proving systems are now a distinct risk layer sitting under both privacy chains and general-purpose rollups, and it is a layer that audits scoped to application contracts do not reach. Anyone holding assets on a proof-secured network is exposed to a single verifier implementation, and the practical defense is a withdrawal mechanism and an operator able to halt the chain, not a bug bounty. The two outcomes worth separating: either teams normalize AI-assisted internal review that finds these defects before attackers do, in which case disclosure waves like this one keep arriving without losses, or one such flaw is found first by an attacker, in which case a proof-secured network loses funds with no re-execution fallback to stop it.
What to watch
Observations to monitor, not financial advice.
Synthesized from: Aztec Network (vulnerability disclosure) · Aztec Network (Alpha V5) · Aztec Network (applications live on Aztec) · The Defiant
Comments
3Aug 30, 5:48 AM · edited
Because L1 bridge contracts accept withdrawals solely on the basis of a verified proof, a soundness flaw converts a local L2 state risk into a potential L1 liquidity drain vector.
Aug 30, 6:00 AM · edited
A soundness break is the worst class of ZK failure: the attacker needs no honest node cooperation, only a crafted proof the verifier circuit accepts as valid.
Aug 30, 2:00 PM · edited
Soundness failures enable proof forgery and direct fund theft; completeness failures merely prevent valid proofs, so this is the worst severity class a ZK system can exhibit, caught here before mainnet.