The bridge hacks of 2022 — Ronin, Wormhole, Nomad, Harmony — ended up becoming a kind of security folklore. "Don't hardcode trusted signers," people said. "Check your initialization," people said. The industry fixed the obvious bugs, moved on, and assumed bridges had grown up.
They hadn't.
In Q1 2026 alone, our benchmark datasets include three separate cross-chain protocols that lost user funds to issues that the 2022 checklists wouldn't have caught. The bugs aren't in the trusted-signer math anymore. They're in the replay semantics — the messy, under-specified boundary where one chain's interpretation of a message disagrees with another's.
The New Shape of Bridge Bugs
The mental model that killed Wormhole — "an attacker forges a valid signature from an untrusted signer" — is basically solved. Modern bridges use BLS aggregation, MPC, ZK validity proofs, or optimistic fraud windows. The math is usually correct.
What's not solved is what happens when a valid message gets replayed somewhere unexpected. The three attacks we see most often in 2026:
3
Recent Bridge Incidents
$180M+
Replay-Class Losses
~6 weeks
Median Time to Exploit
100%
Preventable
1. Nonce Domain Collision Across Message Types
Many multi-message bridges use a single nonce sequence across different message types — "transfer," "governance update," "fee update," and so on all increment the same counter. The rationale is gas efficiency: one storage slot, atomic ordering.
The bug: if the message-type field isn't in the signed payload, an attacker who can observe a legitimate "fee update" signed by the bridge operators can re-broadcast it as a "transfer" message on the destination chain. The signature is valid. The nonce is valid. The message-type parser just decodes the bytes differently on the destination.
We saw this exact pattern cost a cross-chain AMM $40M in Q1. The fix is trivial — include message type in the hash — but the bug is easy to introduce when two teams work on separate message handlers and share a nonce registry.
2. Chain-ID Confusion in Finality Checks
Optimistic bridges (and some ZK bridges with external verifier setups) check that a message originated on a specific source chain by consulting a sourceChainId field in the message. This field is usually a uint16 or uint32 enum that maps to an internal registry.
When a new chain is added to the registry, its ID is often appended to the end. If the registry is upgradeable and its state is replicated across destination chains via the bridge itself, there's a window during rollout where the chain-ID mapping is inconsistent.
⚠️The exploit window
During the 24-72 hours when a new chain is being added, the destination contracts on already-supported chains may not yet recognize its ID. An attacker who can submit a message before the registry update propagates can claim origination from a chain that doesn't exist in the destination's view — and the default fallback (usually "trust the caller") applies.
A chain-ID registry update needs to be atomic across all destinations or gated by a cooldown. Neither is easy to enforce without a proper governance framework, which most bridges don't have.
3. Replay Across Fork Events
This is the subtlest of the three. When a chain undergoes a hard fork — especially a contentious one — old state history can become ambiguous. A message that was executed on the pre-fork chain may appear "unexecuted" on a post-fork replica if the bridge's executed-message registry was stored on the forked chain.
The Ethereum ecosystem had exactly this scare during the 2025 Pectra upgrade, when an L2 that hadn't yet migrated its execution-tracking tables would have replayed messages had anyone tried. No one exploited it, but the window existed for about ten days.
More practically: every time a chain goes through a major upgrade, every bridge touching it should be in "paused withdrawal" mode for the duration. Most aren't. Audits rarely flag this because it's an operational concern rather than a code bug — but the vulnerability is real and the loss is unbounded.
What Modern Bridge Audits Need to Check
The 2022-era bridge audit checklist was essentially:
- Trusted signer set is what you think it is
- Signature verification math is correct
- Nonce prevents same-message replay
- Reentrancy guards on withdrawal
All of that is still necessary. None of it is sufficient. The 2026 additions:
Message-type binding
Every field that affects execution semantics — message type, target, data, destination chain — must be in the hash. Not just the payload.
Chain-ID immutability
Destination contracts should treat their own chain ID as an immutable constant, read from block.chainid at every validation call.
Registry propagation delays
If the bridge has any upgradeable registry replicated across chains, audits must simulate the out-of-sync window and confirm no privilege escalation is possible.
Fork-safety plan
Every bridge needs a documented procedure for pausing during chain upgrades. Audits should flag the absence of this as a critical operational finding.
Executed-message storage location
The registry that tracks which messages have been executed must live on the destination chain, never derived from the source chain's state — otherwise a source-chain reorg becomes a replay vector.
How RedVolt Tests Bridges
Our smart contract audit engine has a dedicated cross-chain analysis mode. When the scope includes bridge contracts, the Viper and Phantom agents are specifically directed to:
- Generate every possible
UserOperation-equivalent message shape and test which ones the destination accepts - Fuzz the chain-ID field with invalid, out-of-range, and aliased values
- Simulate registry update timing attacks with controlled block gaps
- Execute forked mainnet PoCs that replay real messages across test-deployed destinations
💡Recent benchmark
In our 2026 cross-chain benchmark, the engine detected 8 of 8 high-severity findings from a Code4rena bridge contest in 7 minutes. Including a nonce-domain collision that the median warden missed. You can see the detailed benchmark data on our Web3 auditor page.
Every finding comes with a Foundry test that demonstrates the exploit — and the audit report includes a pause-playbook for each operational finding, not just remediation code.
The Broader Point
Bridges aren't easier to secure today than they were in 2022 — they're harder. The trusted-signer bugs are mostly fixed, but the attack surface has grown into message semantics, chain coordination, and operational gaps that didn't exist when cross-chain was one message type and two chains.
If you're building a bridge, or relying on one to move a significant treasury, three things you can do this month:
- Audit the replay surface specifically — not just the cryptography
- Write an incident response runbook for source-chain upgrades and forks
- Add a pause guardian that can halt all withdrawals on 30 seconds' notice, and rehearse it quarterly
The next Wormhole is already out there. It won't look like the last one.
RedVolt audits cross-chain protocols against a dedicated replay and coordination test suite. Request a bridge audit.