BlockSec Reveals Cause of $2.15M Aztec Network Hack
Security firm BlockSec Phalcon posted fresh details on X today, June 15, 2026, and revealed the exact cause behind the Aztec Network incident which led to a loss of more than $2.15 million. The updated analysis overturns earlier assumptions and points to a subtle but a critical flaw in how the rollup processed transactions.
On June 14, 2026, hackers stole $2.15 million from Aztec Connect. The network immediately acknowledged the exploit and posted on social media platform X informing that this attack does not affect Aztec Network’s current system or their token.
Initial Alert Misidentified the Problem
Just a few hours before the detailed post, Phalcon Security had issued an alert about a suspicious transaction targeting Aztec Network’s RollupProcessorV3 contract on Ethereum. The initial report suggested that there had been a missing access control that had been issued. It appeared the processRollup function did not enforce requirements for an authorized rollup provider or escape hatch. This would have allowed arbitrary callers to submit rollup proofs including withdrawal proofs.
The team quickly pivoted after diving deeper into the technical details. Their updated conclusion shows the real problem was far more specific and involved a mismatch in transaction counting logic.
Transaction Set Mismatch Created the Vulnerability
The actual root cause was a mismatch between the verified rollup transaction set and the L1 settlement processing boundary. In technical terms, this meant numRealTxs did not properly match _numTxs. This mismatch allowed two parts of the system to interpret the same transaction list differently.
In Aztec Connect’s RollupProcessorV3 processRollup function, the numRealTxs value was not effectively bound to the transaction set enforced by the zero knowledge proof. The proof verification path and the L1 settlement logic ended up reading different numbers of transactions from the same data.
The ZK proof covered all transactions decoded from encodedInnerTxData and inserted their notes into the rollup Merkle tree. Meanwhile, the L1 settlement logic handled only the first numRealTxs decoded slots. This gap in enforcement opened the door for exploitation.
How the Attacker Executed the Exploit
Because the assumption was not enforced, an attacker could place a non-actionable transaction in the scanned slot and move a real deposit into a later decoded slot. In the observed exploit pattern, the attacker set numRealTxs to 1 while placing a real deposit transaction in the second decoded transaction slot.
The rollup credited value internally while skipping the corresponding L1 signature validation and pending deposit balance deduction. The second slot deposit bypassed the decreasePendingDepositBalance function and therefore did not consume the corresponding pending deposit balance. This created unbacked private balances that could later be withdrawn through normal settlement flows.
In the attack transaction, the attacker first credited seven unbacked asset balances across different assets into the rollup state. They then extracted those assets into the rollup state. They then extracted those assets through seven subsequent withdrawals. The team used the first DAI deposit and withdrawal pair as an example to illustrate how the exploit worked.
Shocking Timeline Raises Audit Questions
The security firm also pointed out an interesting detail which surrounds the timeline of events. According to Aztec’s official sunset notice, the Aztec Connect rollup would continue processing transactions and withdrawals only until March 31, 2024. After that date, the sequencer would stop running.
However linked materials indicate that RollupProcessorV3 was still upgraded on April 10 2024 via PR 67. This upgrade happened after the official sunset date. The upgrade appears not to have gone through an external audit before deployment. This raises serious questions about security practices during the sunset period.
Why This Matters for Crypto Security
It is interesting how small mistakes in transaction counting could lead to such a big financial vulnerability. However, the bug was neither related to the lack of permissions nor access control problems; rather, it was due to a mistake in reading the same data by two different parts of the system. This sort of mistake is usually extremely hard to find through audits.
Additionally, there is a problem of contract upgrading past the sunset date. It seems that a deprecated contract can still be quite vulnerable because of constant improvements.
