Cross-chain bridges are the most attacked infrastructure in all of Web3. Since 2021, bridge exploits have accounted for over $2 billion in losses — more than any other category of smart contract vulnerability.
The reason is simple: bridges hold enormous amounts of locked assets, and their security model is fundamentally more complex than single-chain contracts.
The Bridge Exploit Hall of Infamy
$625M
Ronin Bridge
$326M
Wormhole
$190M
Nomad
$100M
Harmony Horizon
These aren't small projects with amateur teams. These were well-funded, audited protocols — and they still fell.
How Bridges Work (Simplified)
Lock
User locks tokens on Chain A into the bridge contract
Verify
Validators or relayers observe the lock event and verify it
Mint
Bridge mints equivalent wrapped tokens on Chain B
Redeem
To go back, user burns on Chain B and unlocks on Chain A
Every step in this flow is a potential attack surface.
The Five Bridge Vulnerability Classes
1. Validator Key Compromise
criticalThe most devastating attack vector. If an attacker gains control of enough validator keys, they can forge messages and drain the bridge.
Compromise validator keys
Through phishing, social engineering, or infrastructure exploitation
Forge withdrawal messages
Create fake proofs that tokens were locked on the source chain
Drain the bridge
Mint or unlock tokens on the destination chain without any real deposits
🛑Ronin Bridge: $625M
The Ronin Bridge used a 5-of-9 multisig. The attacker compromised 5 validators (4 from Sky Mavis + 1 third-party). With threshold control, they forged withdrawals and drained the bridge. It took 6 days for anyone to notice.
2. Message Verification Bypass
criticalBugs in the verification logic that allow forged or manipulated cross-chain messages to be accepted as valid.
Wormhole Exploit Pattern
The Bug
The Wormhole bridge on Solana used a deprecated function to verify guardian signatures. The function didn't properly validate the signature account.
The Exploit
Attacker created a fake SignatureSet account that appeared valid to the verification logic, bypassing guardian approval entirely.
The Result
Minted 120,000 wETH ($326M) on Solana without any corresponding deposit on Ethereum.
3. Faulty Proof Verification
criticalWhen the bridge accepts proofs that don't actually prove what they claim.
Default proof initialization
The Nomad bridge initialized its trusted root to 0x00, which is the default value for any uninitialized bytes32
Any message is valid
Since unprocessed messages map to 0x00 in the Merkle tree, and the trusted root was also 0x00, every message was automatically trusted
Copy-paste exploitation
Once the first attacker figured it out, anyone could copy the transaction, change the recipient address, and drain funds. Hundreds of wallets participated.
⚠️Nomad: The First Decentralized Exploit
The Nomad exploit was unique because it required zero technical skill after the first transaction. Bots and random users simply copied the attack transaction and changed the recipient. $190M was drained in hours.
4. Replay Attacks
highCross-chain messages that can be reused or replayed:
- Same-chain replay — Using a valid withdrawal proof multiple times on the same chain
- Cross-chain replay — Using a proof meant for Chain A on Chain B (when the bridge operates on multiple chains)
- Post-upgrade replay — Old proofs that become valid again after a contract upgrade changes validation logic
5. Economic and Governance Attacks
high- Flash loan attacks on bridge governance to change validator sets
- Manipulating liquidity-based bridges by draining one side
- Oracle manipulation to affect bridge pricing
- Validator collusion in small validator sets
The Root Causes
Why Bridges Are Harder
- •Trust assumptions span multiple chains and networks
- •Message verification logic is custom and complex
- •Validator management adds offchain attack surface
- •Huge TVL creates massive incentives for attackers
Single-Chain Contracts
- •Trust assumptions are well-defined within one chain
- •Standard patterns (ERC-20, etc.) are battle-tested
- •No offchain infrastructure to compromise
- •TVL typically smaller and more distributed
Bridge Security Checklist
ℹ️What We Look For in Bridge Audits
Message verification logic (can proofs be forged?). Replay protection (are nonces enforced?). Validator management (can the set be compromised?). Upgrade mechanisms (can upgrades invalidate security assumptions?). Rate limiting (can the bridge be drained in a single transaction?). Emergency pause mechanisms.
Design-level defenses:
- Large, decentralized validator sets (15+ independent validators)
- Multiple confirmation requirements before releasing funds
- Rate limiting on withdrawals (max X% of TVL per hour)
- Fraud proofs or optimistic verification with challenge periods
- Emergency pause functionality with monitoring
- Regular key rotation for validators
The Audit Approach
Architecture Review
Analyze the trust model, validator set, and message flow
Verification Logic
Fuzz and formally verify all proof validation code
Economic Analysis
Model incentive alignment and attack profitability
Infrastructure Review
Assess validator security, key management, and monitoring
Building or operating a cross-chain bridge? The stakes are higher than any other category in Web3. Request a bridge security audit — our team combines AI-powered code analysis with deep expertise in cross-chain security models.