Top 3 Security Incidents in June
June's three largest incidents didn't stem from any single bug. They exposed a shared failure. On the surface, a security guarantee looked intact, but underneath it was never actually enforced. A MEV bot trusted trades that appeared profitable without confirming that allowances were truly consumed. Two retired rollups accepted proofs that were valid in form but never bound to the settlement state they claimed to represent. A wallet's signing code silently dropped the one secret input its security depended on, turning a value that was supposed to be unpredictable into something anyone could recompute from public data. None of these systems was broken by brute-force cryptanalysis. They were broken by an assumption nobody ever checked.
Best Security Auditor for Web3
Validate design, code, and business logic before launch
On June 20, 2026, JaredFromSubway, an Ethereum MEV bot operator, was drained of approximately $15M in a honeypot attack.
The attacker built a fake trading environment with fake wrapper tokens and fake Uniswap V2-style pools that emit realistic Swap / Sync events. In a legitimate flow, the wrapper contract's wrapTo() function should internally call transferFrom() on the underlying real token, consuming the allowance the bot had previously granted. However, the fake wrapper token contract skipped this step entirely while still returning a small attacker-crafted profit through unwrap(). Because the bot did not verify whether allowances were actually consumed or revoke residual approvals, unconsumed allowances accumulated and were later harvested through withdraw(). One affected wallet lost roughly 1,474.58 WETH, 2,870,573 USDC, and 2,035,760 USDT. JaredFromSubway later reported a total loss of approximately $15M across affected wallets.
The lesson is that MEV bots need to treat unknown token and pool code as hostile, even when simulations appear profitable. Automated strategies require strict spender allowlists, code-hash checks, post-trade allowance verification, and cleanup of residual approvals.
Aztec Legacy Rollup Incidents: ~$4.35M
In June 2026, two separate legacy Aztec deployments were exploited, together resulting in approximately $4.35M in losses. Although the root causes were different, both incidents occurred at the boundary between proof validity and settlement semantics.
The first incident hit Aztec Connect's RollupProcessorV3 on June 14, 2026, causing approximately $2.15M in losses. The attacker set numTxs to 1 while sneaking a real deposit into a later, decoded slot, so the proof path credited the value internally while the L1 settlement logic skipped the corresponding decreasePendingDepositBalance() invocation. The attacker then withdrew the resulting unbacked balance through normal channels.
The second incident struck a separate legacy PrivateRollupBridge / RollupProcessor deployment on June 18, 2026, resulting in about $2.2M in losses. This deployment still exposed an escapeHatch(bytes,bytes,bytes) path, and its circuit never constrained the private join-split membership root to match the public oldDataRoot consumed by L1. This allowed the attacker to prove ownership of high-value notes in a fake private tree while publishing the real L1 dataRoot as the public root. The verifier accepted the proof, and the L1 contract executed the withdrawal.
Together, these incidents show that proof verification alone isn't enough. Every value that governs settlement boundaries must be bound to the exact public inputs the proof verifies, and every private witness must be explicitly constrained to match the public state settlement actually consumes.
SecondFi: ~$2.4M
On June 23, 2026, SecondFi (formerly Yoroi), a browser wallet extension developed by EMURGO, disclosed a critical flaw in its Ed25519 signing implementation, affecting versions v10.0.3 through v10.0.6.
The vulnerable code derived the signing nonce from only the public transaction message, omitting a required secret nonce prefix. That turned the signature equation into a single unknown, letting anyone recover a wallet's private key directly from public on-chain data. Two attackers exploited the flaw independently, draining approximately $2.4M (16M ADA) from 374 wallets before EMURGO rescued a further 129M ADA.
The lesson is that wallet signing code needs the same scrutiny as protocol-level cryptography. Omitting a single secret input, even one that looks minor, can fully compromise private keys, so custom Ed25519 implementations should go through an independent audit rather than being trusted like a standard library.
Honorable Mention: Zcash Orchard soundness bug
It didn't make the Top 3 ranking because no exploitation has been confirmed, but Zcash's Orchard soundness bug was one of June's most significant disclosures. Publicly disclosed on June 4, 2026, the bug was a missing equality constraint in the Orchard shielded pool circuit that could have allowed the same shielded note to produce different nullifiers and be spent more than once. The flaw had existed since Orchard's activation in May 2022 and was patched via the NU6.2 emergency upgrade.
The incident reaffirms the deeper lesson from the Aztec case. In a ZK system, security depends on what the circuit actually constrains—not on what the surrounding protocol assumes it constrains.
Read the Zcash Orchard bug analysis
The information above is based on data as of 00:00 UTC, July 1, 2026.
This concludes the June security incidents brief.
You can learn more in our Security Incidents Library.
Stay informed and stay secure!
