Cross-Chain Bridge Security: Risks, Real Hacks, and What to Audit

Updated on October 27th, 2026

Cross-chain bridges are the single most expensive point of failure in Web3. Between 2021 and Q3 2025, attackers took roughly $2.9 billion in 34 bridge hacks, according to Global Ledger. In April 2026, the Kelp DAO incident added about $290 million more, the largest DeFi exploit of the year.

The pattern behind these losses is consistent. Bridges hold large pools of locked assets, and they ask one blockchain to accept a claim about another. When that claim can be forged—through stolen keys, a skipped signature check, or a bad upgrade—the bridge pays out to the attacker.

For founders, CTOs, and security leads, bridge security is a set of business decisions, not only an engineering problem. Which verification model do you build on or integrate? How much value can you let one compromise put at risk? What do you audit, when, and how much bounty does the risk justify?

This guide answers those questions. It compares bridge security models by fit, shows who owns the risk when you integrate a third-party bridge, breaks down what past breaches cost beyond the stolen funds, and sets out what a bridge audit should cover and when.

What Is a Cross-Chain Bridge?

A cross-chain bridge is a protocol that moves assets or messages from one blockchain to another. Blockchains cannot read each other's state, so a bridge has to observe an event on the source chain and prove it to the destination chain.

Most token bridges work in one of two ways:

• Lock-and-mint. The bridge locks tokens in a contract on chain A and mints a wrapped version on chain B. Burning the wrapped token on chain B releases the original on chain A.
• Liquidity pools. The bridge holds liquidity on both chains. A user deposits on chain A, and the bridge pays out from its pool on chain B.

Either way, the bridge ends up custodying a large pool of value. That pool is backed only by the bridge's ability to tell a real cross-chain message from a fake one. This is why the core security question for any bridge is simple: who or what verifies that an event on the other chain really happened?

Bridge Security Models: How Bridges Verify Transfers

A bridge's security model is defined by how it verifies cross-chain messages. Older guides split bridges into sidechains, Plasma, or "trusted vs. trustless." A more useful split looks at who has to be honest for the bridge to stay safe.

No model removes risk. Externally verified bridges concentrate it in keys. Natively verified bridges move it into complex verification code. Optimistic bridges depend on someone watching. The safest bridges combine models—for example, a light client plus an independent signer set that must agree before large withdrawals.

Are Decentralized Bridges More Secure Than Centralized Ones?

Decentralized bridges remove the single point of failure, but they are not automatically more secure. They trade key-management risk for code risk, and the code is usually far more complex.

Centralized and small-committee bridges fail when keys fail. Ronin needed 5 of 9 validator signatures, and attackers obtained exactly five. Harmony's Horizon bridge needed only 2 of its multisig signers. In both cases, the smart contracts worked as designed—the signers were the weak point.

Decentralized bridges fail when verification logic fails. Wormhole's guardian network was not compromised in 2022. Instead, a deprecated function let an attacker skip signature verification and mint 120,000 wETH. Nomad's optimistic design was sound on paper, but a routine upgrade made every message count as proven.

What actually separates secure bridges from insecure ones:

• Size of the trust set. A 5-of-9 or 2-of-5 threshold can be broken with a handful of compromised machines. Larger, independent signer sets raise the cost of an attack.
• Independence of signers. Nine keys run by one company are one target. Signers spread across organizations, infrastructure, and jurisdictions are many.
• Quality of verification code. Light clients and ZK verifiers are only as strong as their implementation and audits.
• Damage limits. Rate limits, withdrawal caps, and pause controls decide whether a breach costs $1 million or $600 million.

The practical answer: a well-run decentralized bridge with audited verification code is more secure than a small multisig. A poorly reviewed decentralized bridge is not.

Build vs. Integrate: Who Owns Bridge Risk?

Integrating a third-party bridge or messaging protocol does not outsource the risk. Most protocols today plug into an existing interoperability layer rather than building one. The provider secures its core protocol, but the integrating team still owns everything it configures and deploys on top.

Recent incidents show where that line sits:

• Kelp DAO (April 2026, ~$290M). The messaging protocol reportedly attributed the exploit to Kelp's own setup, including the use of a single verifier. Kelp disputed that account. Either way, the configuration choice was at the center of the loss.
• CrossCurve (February 2026, ~$3M). CrossCurve's own receiver contract, built on top of a third-party messaging network, let a spoofed message bypass gateway validation and trigger an unlock.
• Hyperbridge (April 2026). A forged message gave the attacker control of a bridged token contract, letting them mint 1 billion tokens.

Before integrating, ask three questions:

1. What is the worst case if the bridge's verification fails? If one forged message could mint or unlock your entire supply, the integration needs caps before launch.
2. Does the default configuration match your risk? Defaults are designed for convenience. Settings appropriate for a small pilot are rarely appropriate for nine figures in TVL.
3. Is your integration code in audit scope? Provider audits cover the provider. Your receiver, adapter, and token contracts need their own review.

Cross-Chain Bridge Vulnerabilities: The Biggest Security Risks

Most bridge losses trace back to six risk classes. The first two account for the largest single incidents on record, and both sit partly outside the smart contracts, which is why contract audits alone have not prevented them.

Access control failures were the leading cause of Web3 losses in the first half of 2025, according to Hacken's yearly security report. For the contract-level bug classes, see our breakdown of smart contract vulnerabilities and how a flash loan attack manipulates pool pricing.

The Biggest Bridge Hacks And What They Teach

The largest bridge hacks were not exotic. Most came down to too few keys, one unchecked function, or one bad upgrade. 2022 alone accounted for 66% of all bridge losses from 2021 to Q3 2025.

Three lessons repeat from 2022 to 2026:

1. Key compromise and verification bugs cause the largest losses. Ronin, Harmony, and Multichain were key failures. Wormhole, Nomad, and Verus were verification failures.
2. Upgrades and configuration are as risky as launch code. Nomad's bug arrived in a routine upgrade. Kelp's incident centered on how a messaging stack was configured.
3. Detection speed decides the size of the loss. Ronin's drain went unnoticed for six days. Nomad was copied by more than 300 addresses within hours once the first exploit landed.

What a Bridge Breach Costs Beyond The Stolen Funds

The stolen amount is only the first line of the bill. Teams that survived major bridge hacks paid again in reimbursement, downtime, and lost trust. Some did not survive at all.

For a decision-maker, the comparison that matters is not the cost of an audit versus zero. It is the cost of layered security versus a loss that can exceed the bridge's TVL, the company's valuation, and the trust of every chain it connects.

How Crypto Bridges Stay Secure

Secure bridges layer controls so that no single failure can drain the pool. The controls below map directly to the incidents above.

How To Know If a Blockchain Bridge Is Secure

You can judge most bridges from public information in under an hour. Whether you are integrating a bridge into your protocol or assessing one as an investor, work through these questions.

If you are evaluating a bridge as part of an investment, the same checks belong in your cybersecurity due diligence for crypto projects.

Blockchain Bridge Audit: What Audits a Bridge Protocol Should Have

A bridge needs more than a standard smart contract audit. Its risk sits across on-chain contracts, verification logic, off-chain services, and operations, so the audit scope has to cover all four. Several of the hacks above happened in components that the original audits never reviewed.

A complete cross-chain bridge audit covers:

1. Smart contracts on every chain. Lock, mint, burn, and unlock logic; access control; reentrancy; amount and decimal handling. A smart contract audit is the baseline, and it must be repeated for each chain the bridge deploys to.
2. Message verification. Signature checks, proof verification, light client logic, replay protection, and source validation. Every path that can trigger a mint or unlock should be traced end to end.
3. Consensus and light client code. For natively verified bridges, the logic that tracks the source chain's consensus needs a reviewer who understands that chain. This overlaps with a Layer 1 protocol audit.
4. Off-chain components. Relayers, oracles, signing services, and APIs. Penetration testing of this infrastructure catches the class of bug behind the Across relayer incident.
5. Upgrade and deployment process. Proxy admin rights, timelocks, initialization values, and migration scripts. Nomad shows why this step cannot be skipped.
6. Key management and operations. Who holds keys, how they are stored, how access is revoked, and how the team would respond to a compromise.
7. Economic design. Stake versus value secured, fee and liquidity mechanics, and resistance to flash loan manipulation.

One audit firm rarely covers all of this with equal depth. Many bridge teams pair a traditional audit with a crowdsourced audit, where many independent researchers attack the same scope. A DualDefense audit adds that crowdsourced layer on top of an existing third-party audit. After launch, a bug bounty keeps the review going as the system changes.

Conclusion

Bridge security comes down to one question: can the bridge tell a real cross-chain message from a forged one, under every condition, including after an upgrade or a key compromise? The biggest losses happened when the answer was no, often because of a small validator set, one missing check, or one untested upgrade.

Teams building or integrating a bridge should review the full system—contracts on every chain, verification logic, off-chain services, upgrade paths, and key operations—and keep testing it after launch.

Frequently Asked Questions