Bridge Hacks Explained: Why Cross-Chain Bridges Keep Getting Exploited
TL;DR
-
Bridges keep getting hacked because every bridge has to solve a difficult problem: proving something happened on one chain to a contract that can't see that chain.
-
Every solution to that problem - locking funds, trusting validators, passing messages - creates a new concentration of trust, and a new target.
-
Three separate bridge exploits hit in the space of about two weeks in June 2026, via three completely different attack vectors.
-
The industry is getting better at detection and disclosure, even as the hacks keep coming.
-
CoW Swap's cross-chain routing is built so the swap leg of your trade never touches a bridge contract at all.
Open a crypto news feed on more or less any given week in 2026 and there's a decent chance you'll find a bridge exploit in it. In the space of about ten days this June alone: Secret Network's bridge to Axelar was drained of $4.67 million after an attacker forged cross-chain messages. A leaked signing key broke the trust model behind Taiko's Ethereum L2 bridge, forcing the entire network to halt and every user to withdraw their funds. And a separate exploit pulled roughly $2 million out of Aztec's bridge to Ethereum.
Three hacks, three completely different root causes, ten days. By some counts, bridges have produced over $340 million in losses across more than a dozen exploits in 2026 alone.
If you've ever wondered why this particular corner of DeFi seems to get hit so much harder than everything else, here's the uncomfortable answer: it's not bad luck, and it's mostly not sloppy engineering either. It's structural. Bridges are solving a problem that doesn't have a clean solution - and every way of solving it creates a new place for things to go wrong.
This piece walks through why that is, what the actual failure categories look like, and what's changing about how the industry handles it.
The problem bridges are trying to solve
Blockchains don't talk to each other. Ethereum has no idea what's happening on Arbitrum. Arbitrum has no idea what's happening on Base. Each chain is its own self-contained ledger, validated by its own set of nodes, with no native way to look across the fence at another chain's state.
A bridge's entire job is to manufacture a way around that. When you bridge a token from Chain A to Chain B, something - a smart contract, a validator set, an oracle network - has to vouch for the fact that you really did lock, burn, or deposit that token on Chain A, so that Chain B is willing to release or mint the equivalent on the other side.
That "something that vouches" is the whole problem. Whatever you choose to do that vouching - a contract holding the asset, a set of validators signing off, a relayer passing messages between chains - becomes a single point that concentrates enormous value and has to be trusted completely. Get it right and the bridge works invisibly. Get it wrong, even slightly, and there's often nothing standing between an attacker and everything the bridge is holding.
The three ways it breaks
Pull apart a few years of bridge hacks and they tend to cluster into three categories - not three different kinds of bad luck, but three different places where the "vouching" can fail.
1. Validation logic flaws
This is what happens when the code responsible for checking "did this deposit actually happen?" has a hole in it - and the contract on the other side mints or releases funds based on a deposit that was never real.
The Wormhole hack in 2022 ($320 million) is the canonical example: an attacker found a way to spoof the signature verification that was supposed to confirm a deposit on Solana, and minted wrapped ETH on the other side without ever depositing anything.
The Secret Network/Axelar exploit from this June is a more recent, smaller-scale version of the same idea. The bridge's contract was supposed to check that incoming cross-chain messages came from a legitimate, allow-listed channel. That check had been disabled. The attacker spun up their own minimal blockchain, opened a channel to the bridge contract, and self-relayed forged deposit messages that the contract accepted as genuine - minting real, redeemable wrapped tokens against deposits that never happened.
Different chains, different code, same underlying failure: the contract trusted a message it shouldn't have.
2. Validator and key compromise
Some bridges don't rely purely on contract logic - they rely on a defined set of validators or operators who sign-off on cross-chain messages. If you can compromise enough of those signers, or steal the right key, you don't need to find a bug in the code at all. You just become the trusted party.
Ronin Bridge ($624 million, 2022) is the largest example of this in DeFi history: attackers compromised five of the nine validator keys securing the bridge, which was enough to forge withdrawals and walk away with the funds.
Taiko's incident this June is a newer twist on the same theme. The exploit had nothing to do with a contract bug - a cryptographic signing key for Taiko's hardware-based prover system had been accidentally committed to a public GitHub repository. Whoever found it could generate proofs the bridge would treat as legitimate. The team halted block production and told every user on the network to withdraw funds from every bridge built on Taiko, because the entire trust model the bridges relied on could no longer be guaranteed.
3. Trusted-root and messaging failures
The third category covers bridges that rely on a "trusted root" - some reference point the contract checks new messages against to confirm they're legitimate. If that reference point is ever misconfigured, even briefly, the contract can end up accepting messages it should reject outright.
Nomad's collapse in 2022 ($190 million) is the textbook case. A routine upgrade set the trusted root to a default, unverified value. Once that was live, any message - forged or not - passed validation. What followed wasn't even a single sophisticated attacker; it was a free-for-all, with bystanders watching it happen in real time and racing to copy the exploit before anyone fixed it.
Why this keeps happening
None of this is really an engineering failure in the sense of "they should have just tried harder." Lock-and-mint bridges, validator-based bridges, and message-passing bridges are three different architectures for the same underlying compromise: to make two chains that can't see each other behave as if they can, you have to put your trust somewhere. A contract. A validator set. A root hash. Wherever that trust lives, it accumulates value - and accumulated value is, by definition, an attractive target.
Bridges aren't unusually badly built. They're unusually exposed, because the thing they do is inherently exposed.
What's actually getting better
It's worth saying plainly: this isn't a story of an industry standing still. Zero-knowledge light clients are replacing "trust a validator set" with "verify a cryptographic proof," which removes an entire category of attack. Decentralized validation and multi-party signing are replacing small, compromise-able validator sets. Rate limiting and circuit breakers - caps on how much value can move through a bridge in a given window - are increasingly standard, turning what used to be a total drain into a contained, partial one.
The response speed to this June's incidents is itself a data point worth noting. Axelar and Secret jointly disclosed their exploit within 48 hours, isolated the affected contract, and were transparent about which integrations were and weren't impacted. Taiko halted the entire network within hours of detecting irregular activity and gave users a clear, immediate instruction. Neither outcome is good news exactly - but a few years ago, disclosure timelines like that would have been unusual. The bar for incident response has moved, even while the underlying attack surface hasn't gone away.
How cross-chain swaps happen on CoW Swap
When you make a cross-chain swap on CoW Swap, the trade is split into two distinct legs. The swap leg - converting one token into another - settles through CoW Protocol's solver competition: a combinatorial batch auction where independent, bonded solvers compete to fill your order. That leg never touches a bridge contract, because there's nothing to bridge yet; it's a same-chain settlement.
The bridging leg, where your assets move from one chain to another, is handled by routing across an aggregated set of vetted bridge providers chosen by route quality rather than defaulted to a single option.
It’s important to state that no aggregator can fully insulate a user from the underlying risk profile of whichever bridge a route sends them through, and that risk doesn't disappear just because it's one step in a bundled flow.
What the split design does mean is that you're not single-sourced to one bridge's contract, validator set, or trust assumptions for your entire trade, and the swap side of the transaction doesn't inherit bridge-specific risk it never needed to carry in the first place.
👉 Try a cross-chain swap on CoW Swap
So what do you actually do with this?
Knowing why bridges break doesn't make any single bridge bulletproof - and it shouldn't stop you from using them, because cross-chain DeFi isn't optional anymore. What it should change is how you evaluate a bridge before you trust it with size: has its validation logic been audited, and by whom? Is it relying on a small validator set or a more decentralized model? Has it had an incident before, and how did it respond when it did?
For the practical side of that - checklist-style, before-you-bridge guidance - see our best practices guide for using cross-chain bridges.
Further reading
-
What are the current best practices for using cross-chain bridges in DeFi?
-
From DEX Aggregator to Bridge Aggregator: CoW Swap's One-Flow Revolution
