Exploit da Ponte Ethereum da Verus: O Mesmo Bug de $11.58M
On May 18, 2026, someone drained the Verus-Ethereum bridge for $11.58 million. According to CoinDesk's reporting, it was the eighth bridge hack of the year. The Verus Ethereum bridge exploit didn't involve some exotic new attack class. It was the same failure we have watched kill bridges since 2021: the contract released funds on one chain without correctly verifying what actually happened on the other.
The vulnerable function had a name this time. checkCCEValues. That's the routine that was supposed to confirm the cross-chain export values matched reality before minting or releasing on the Ethereum side. It didn't do its job, and the attacker walked.
I've spent four years building bridge-adjacent infrastructure in a regulated context, and the depressing part is how predictable this has become. We keep renaming the same wound.
The Verus Ethereum bridge exploit was a source-validation failure
Strip away the branding and every bridge does one thing. It observes an event on chain A (a deposit, a lock, an export) and produces a corresponding action on chain B (a mint, an unlock, a release). The entire security model collapses to a single question: does chain B actually believe what chain A told it, and did it check?
When the validation that confirms source-side amounts is wrong, the answer becomes "no." The attacker forges or inflates the claimed export value, the destination contract trusts it, and tokens that were never backed get minted or freed. The Block reported the loss at roughly $11.58 million, drained through exactly this kind of accounting gap in the cross-chain export check.
This is source amount validation in a bridge, and it is the most load-bearing function in the whole system. Get it wrong by one comparison and the bridge becomes a free money printer.
checkCCEValues is just the newest name for an old vulnerability
The checkCCEValues vulnerability is structurally identical to bugs that have already cost the industry billions. The names rotate. The mechanism does not.
- Wormhole, 2022: a signature verification gap let an attacker mint 120,000 wrapped ETH that was never deposited.
- Nomad, 2022: a botched merkle root initialization meant any message validated as true, and the bridge got copy-pasted to death by a crowd.
- Multichain, 2023: keys and trust assumptions that nobody could actually verify from the outside.
Each of those was, at its core, the destination chain releasing value without a sound proof of the source event. checkCCEValues is the 2026 spelling of the same word.
I think the industry keeps treating these as individual engineering mistakes when they are a category failure. You don't fix a category by auditing one function harder.
Tornado Cash funded the attacker, which tells you about intent
The attacker's wallet was funded through Tornado Cash before the exploit. That detail matters less for attribution than for what it says about preparation. This wasn't a whitehat poking at a contract who got surprised by the result. The Tornado Cash funded attacker pattern is the signature of someone who set up operational cover days in advance and expected the funds to need laundering on the way out.
That's the part defenders underrate. By the time the exploit transaction lands, the off-ramp is already built. Post-hoc tracing helps prosecutors, but it does almost nothing for the protocol that just lost eight figures.
Bridge security failures are now a monthly tax
Zoom out and the Verus hack is a line item, not an outlier. Per PeckShield data cited by Bitcoin.com, crypto bridge exploits added up to roughly $328 million in May 2026 alone. Eight bridge incidents in under five months of the year.
The market has quietly priced this in as a cost of doing cross-chain business. That's the wrong lesson. A recurring nine-figure monthly loss isn't volatility, it's a structural defect that the design space refuses to confront.
For anyone moving real value, the takeaway is uncomfortable: most bridges are trust assumptions wearing a math costume. I've argued before, in How Stablecoin Bridges Actually Fail, that the safest bridge is often the one that admits how little it actually verifies.
What an actually defensible bridge check looks like
If you're building or auditing a bridge, the source amount validation is where you should spend a disproportionate share of your paranoia. A few things I'd treat as non-negotiable:
- The destination contract must verify a cryptographic proof of the source event, not a relayer's word for it. Light-client or zk proofs over multisig attestations wherever the latency budget allows.
- Amount checks must be exhaustive on every path. The
checkCCEValuesclass of bug usually hides in a branch that some inputs skip. Fuzz the comparison, don't eyeball it. - Rate limits and circuit breakers per asset, so a forged value can't drain the whole reserve in one transaction. A cap that auto-pauses at, say, 5% of TVL per hour would have blunted most 2026 incidents.
- Independent invariant monitoring that watches total minted versus total locked in real time and halts on divergence.
None of that is novel. The audit stack to catch these exists, which I dug into in the audit-stack piece. The problem is that bridges keep shipping the validation as an afterthought instead of the product.
The next bridge hack of 2026 is already being written. It will have a different function name and the same root cause, and we'll act surprised again. We shouldn't.