Aztec Connect: Two Incidents, Two Root Causes, One

The Aztec Connect exploit is not a single incident but two distinct events spanning 2023–2026, each revealing different vulnerability classes. The answer to whether this signals broader ZK proof vulnerabilities is nuanced: the 2026 exploit targeted smart contract logic, not ZK cryptography itself—but the 2023 bug did reveal a genuine ZK circuit flaw.

---

Incident Timeline

---

Root Cause Analysis

2023 Vulnerability (Prevented)

The 2023 bug bounty discovery revealed a ZK circuit arithmetic flaw in the claim proof system. Integer division for user DeFi interaction outputs was implemented incorrectly in ZK circuits operating over finite fields.

Two specific bugs were identified:

1. Top Limb Overflow: Values split into 4 limbs (68 bits each) for decomposition, but the top limb was constrained to only 68 bits when it should have accommodated larger values, allowing overflow manipulation.

2. Unconstrained Remainder: The remainder value had no range constraints whatsoever. The equation user_output × total_input + remainder = total_output × user_input could be satisfied by varying user_output and computing an appropriate remainder, enabling multiple valid decompositions for a single value.

Attack vector: Only exploitable by a malicious sequencer via an escape hatch mechanism, who could manipulate user_output and adjust the remainder to satisfy the equation, enabling TVL theft. The patch applied tighter constraints for direct mapping between original and decomposed values, strict range constraints on remainder values, and prohibition of ad-hoc primitive implementations.

2026 Exploit (Actual)

The June 2026 exploit targeted the deprecated RollupProcessorV3 contract and stemmed from a mismatch between verification and settlement logic.

BlockSec (Phalcon) analysis found the core vulnerability was a mismatch between numRealTxs and _numTxs parameters. Verified transactions on the Aztec Connect contract were "not effectively tied" to the transaction set enforced by the ZK proof [Source: https://phalcon.zerion.io].

CertiK analysis found that the computeRootHashes() function only checked the start of proof data, while token transfer parameters were buried in the middle of proof data and not properly validated [Source: https://certik.com].

Technical mechanism:

1. Attacker exploited the public rollup processing function (remained callable on immutable contracts)
2. numRealTxs was read from calldata offset 4516 with no on-chain constraints—attacker controlled this value directly
3. L1 settlement cycle processed only 1 slot (first slot with proofId=0, publicValue=0)
4. Gap slots [2..32] contained fake deposits but received zero L1 validation
5. ZK circuit SHA256 precompile covered all 32 slots, but failed to constrain gap slot publicValue to 0
6. Result: 31 out of 32 slots bypassed validation entirely

Attack Flow:

• Phase 1 (Minting): 7 rollups created unbacked balances by exploiting verification/settlement mismatch
• Phase 2 (Withdrawal): 7 rollups withdrew across multiple assets (ETH, DAI, wstETH, yvDAI, yvWETH, LUSD, yvLUSD)

Why No Response Was Possible: Aztec Labs renounced admin keys upon deprecation. Contracts became fully immutable—no pause, no upgrade, no emergency intervention. Aztec Labs stated: "Aztec Labs holds no admin keys and cannot pause or upgrade the system." [Source: https://aztec.xyz] [VERIFIED: Multiple independent sources (Binance, Keystone Wallet, KuCoin) confirm this claim per https://keyst.one]

---

Is This a ZK Proof Vulnerability?

No for 2026. Yes for 2023. The exploit was not a vulnerability in zero-knowledge proof cryptography itself. The ZK proof system functioned correctly. The vulnerability resided in the smart contract layer where proof verification logic interacted with settlement logic.

---

Broader ZK Proof Ecosystem Implications

The 2023 incident does signal systemic risks. The broader ZK ecosystem has documented 25+ known vulnerabilities across multiple projects [Source: https://0xparc.org]:

Common vulnerability categories: Under-constrained circuits, unconstrained values, arithmetic overflow/underflow, nondeterministic outputs, and unused public inputs.

The 2026 exploit reveals critical design pattern issues applicable across the ZK rollup ecosystem:

1. Verification-Settlement Binding: ZK proof verification must strongly bind all transaction parameters. Partial verification (checking only headers) is insufficient. Settlement logic must enforce identical transaction sets as proof logic.

2. L1/L2 Boundary Security: Upper bound of ZK-Rollup settlement loop must strictly align with range of ZK public input commitments. L1 cannot outsource verification responsibility to circuit layer. Every public input slot committed by ZK proof must be independently verified at L1.

3. The "Ghost Ship Problem": Deprecated contracts remain on-chain indefinitely with no patching capability. Aztec Connect was deprecated March 2023 and exploited June 2026—3 years later.

4. Audit Gaps in Sunsetted Systems: BlockSec noted an April 2024 update to the RollupProcessorV3 contract that "was not reviewed through an external audit before deployment." [Note: This claim is attributed to BlockSec and has not been independently confirmed]

---

Key Takeaways

---

Current Status

• Aztec Network (current): Unaffected
• AZTEC ERC-20 token: Unaffected
• Legacy Aztec Connect Router Contract: Drained
• Stolen funds: 100% remain untouched in attacker EOA 0x0F18D8b44a740272f0be4d08338d2b165b7EdD17 (as of June 15, 2026)

---

Conclusion

The Aztec Connect incidents do partially signal broader ZK proof vulnerabilities—but only through the 2023 bug. The 2026 exploit was a smart contract logic flaw, not a ZK cryptographic failure. However, the 2023 ZK circuit vulnerability (unconstrained remainder, top limb overflow) shares common patterns with documented bugs in Polygon zkEVM, PSE, Scroll, and Dusk Network—suggesting under-constrained circuit design is a recurring systemic risk across the ZK ecosystem, not an Aztec-specific issue.

What remains open: Independent verification of BlockSec's April 2024 update claim; exact mechanism for gap slot publicValue constraint failure not fully detailed; current fund status as of June 15, 2026 not confirmed on-chain.

---

Suggested next steps:

1. Audit gap investigation: Request independent verification of the BlockSec-reported April 2024 contract update that was not externally audited—this directly addresses the "audit gaps in sunsetted systems" pattern identified.
2. ZK circuit pattern scan: Cross-reference the under-constrained remainder/overflow patterns from Aztec, Polygon zkEVM, and PSE against other active ZK rollups (zkSync, StarkNet) to assess whether similar vulnerabilities exist in production systems.