What Is a Cross-Chain Bridge Exploit and How Do These Attacks Happen?

What Is a Cross-Chain Bridge Exploit?

A cross-chain bridge exploit is the abuse of a vulnerability in a bridge, infrastructure that lets different blockchains communicate with each other. Through such a vulnerability, an attacker can, for example, release tokens without a valid deposit, mint tokens without enough collateral, or drain reserves from the bridge.

A cross-chain bridge makes it possible to move tokens, messages, or other data between separate blockchains. That is necessary because a blockchain cannot automatically check what happened on another blockchain.

An exploit can happen in different places. Think of a mistake in message verification, overly broad access rights, a vulnerability in smart contracts, or stolen private keys from validators or administrators. In some bridges, validators, for example, confirm that a message from one blockchain is real and valid before anything happens on the other blockchain.

Important to know: a bridge adds an extra security layer on top of the blockchains it connects. In some bridges, you rely on an external group of validators or a multisig. Other bridges use light clients and cryptographic proofs, such as Merkle proofs, to check that a transaction or event really happened on the other blockchain. So the security model, and with it the risks, can differ a lot from one bridge to another.

By the way, a phishing page during bridging is not automatically a bridge exploit. Such a page can send you to a malicious contract or trick you into signing an unwanted approval, but that does not necessarily mean the underlying bridge itself has been hacked.

Key Takeaways

• A cross-chain bridge makes communication and value transfers between separate blockchains possible.
• A bridge exploit abuses a technical or operational vulnerability in such a bridge.
• Attackers can, among other things, cause unauthorized payouts or mint tokens without enough collateral.
• Verifying cross-chain messages is an important security point for a bridge.
• The security model differs from bridge to bridge and determines what extra risks users face.

How Does a Cross-Chain Bridge Work?

A cross-chain bridge looks at an event on the source blockchain and, after that event has been verified, carries out a matching action on the destination blockchain.

Say you want to send a token from blockchain A to blockchain B. Blockchain B cannot automatically check whether you really sent that token on blockchain A. That is why the bridge has to observe and verify the event on blockchain A before anything happens on blockchain B.

A commonly used model is called lock-and-mint. Your original tokens are locked on the source blockchain. Then a wrapped token is minted on the destination blockchain: a representation of the original token. If you go back, the wrapped token is burned and the original tokens can be released again.

Example: You lock 1 token on blockchain A. After verification, you receive 1 wrapped token on blockchain B. So your original token does not literally travel to blockchain B, but stays locked as collateral for the token you receive there.

Another approach uses liquidity pools. After a verified transaction on the source blockchain, a pool on the destination blockchain can pay out an equivalent amount of tokens.

The crucial step is always verification. For example, the bridge has to check whether a message is real, comes from the right blockchain, meets the right conditions, and has not already been processed. How that happens differs from bridge to bridge.

Some bridges also support generalised message passing. In that case, they can do more than move tokens. They can also pass and execute other data or commands between blockchains. That offers more possibilities, but it can also increase the attack surface.

What Different Security Models Do Bridges Use?

Not every bridge decides in the same way whether a message is valid. Because of that, the security model can differ a lot too.

For example, a bridge may rely on:

• External validators or multisigs: a group of parties signs messages before they are executed on another blockchain.
• Light clients: one blockchain checks cryptographic information about the state of the other blockchain.
• Cryptographic proofs: a bridge uses Merkle proofs or other cryptographic constructions, for example, to prove events.
• Optimistic verification: messages are accepted first, but there is a period during which other parties can challenge an invalid message.

These models involve different trade-offs. An external validator group may be simpler, for example, but it adds another layer of trust. A bridge that checks events cryptographically has different technical risks. That is why the word "bridge" alone says very little about how safe the system actually is.

How Can a Cross-Chain Bridge Be Attacked?

An attacker usually tries to bypass the bridge's verification or gain the power to approve an invalid cross-chain message anyway.

The idea behind that is simple: if the destination blockchain wrongly believes that tokens were deposited or locked on the source blockchain, the bridge can, for example, mint new tokens or release reserves without enough collateral behind them.

This can happen in several ways:

• A bug causes an unproven or forged message to be accepted anyway.
• An attacker gets enough private keys from validators, multisig signers, or administrators.
• A bug in a smart contract skips an important check or gives an account too many rights.
• The verification of a cryptographic proof, such as a Merkle proof or light-client proof, contains an error.
• A wrong configuration or upgrade causes invalid messages to be treated as valid anyway.

A Merkle proof is a compact cryptographic way to show that certain data is part of a larger dataset, for example the data in a block. If a bridge checks such a proof incorrectly, an attacker may be able to get an event accepted that never actually happened validly.

So not every attack goes through stolen keys, and not every bridge works the same way. To understand the risk, you need to look at the bridge's specific verification and security model.

What Vulnerabilities Are Common?

Many bridge attacks fall broadly into a few categories: access control bugs, logic bugs, message verification problems, and operational security problems.

Permission issues are about who is allowed to do what. Maybe an admin account has too many rights, validator accounts are not protected well enough, or permissions can be changed incorrectly. Especially with a small validator or multisig set, this can be a major risk. If enough signers work together or are compromised, they can authorize invalid payouts.

Logic issues are bugs in the rules of smart contracts. For example, a contract processes a message without checking all conditions, or minting and release are set up incorrectly. Bugs during an upgrade or during contract initialization can also fall into this category.

Message verification issues happen when a bridge does not check well enough whether a cross-chain message is actually valid. For example, a bridge may accept the wrong source, check a cryptographic proof incorrectly, or execute a message that never became valid on the source blockchain.

Key management issues happen when private keys from validators, administrators, or multisig signers are stolen or not protected well enough. The smart contracts may work correctly from a technical standpoint, while an attacker can still produce valid signatures with stolen keys.

Replay attacks are also a known risk. In these attacks, a previously valid message is used again. A bridge therefore has to check that each message can only be processed once. A unique message ID, nonce, or hash can help with that.

An audit can help find vulnerabilities, but it is no guarantee that a bridge is bug-free. Especially after upgrades, changed settings, or changes in off-chain infrastructure, new risks can appear.

How Do Frontends and Phishing Play a Role?

Not every loss while using a bridge means the bridge itself was exploited. Attackers can also try to trick users through a fake website or interface.

A fake interface can, for example, make you send a transaction to the wrong smart contract or approve token use from your wallet. The bridge's technical infrastructure can remain fully intact in that case.

The difference matters: in a bridge exploit, a weak spot in the bridge or the infrastructure around it is abused. In phishing, the user is usually tricked into approving a harmful action themselves.

How Can Private Keys and Smart Contracts Play a Role?

Private keys and smart contracts are important parts of many bridges. A problem in either one can already have serious consequences.

A private key is a secret key used to create transactions or cryptographic signatures. If a bridge only pays out after multiple validators have signed, for example, a major risk appears when an attacker manages to get enough of those keys. The attacker can then get fraudulent bridge instructions approved as if they were legitimate.

A multisig requires multiple parties to sign before an action goes through. That can be safer than one admin account, but it is not automatically safe. The threshold has to be chosen well, signers need to be sufficiently independent, and private keys have to be protected properly.

In the Ronin Bridge attack, enough validator keys were compromised in March 2022 to approve unauthorized withdrawals. In the end, 173,600 ETH and 25.5 million USDC were taken from the bridge. The bridge design was later adjusted and additional security measures were added.

In the Harmony Horizon Bridge incident, at least two of the four private keys of bridge validators were compromised in June 2022. Harmony said there was no evidence that the bridge smart contracts or the blockchain protocol itself had been affected. The incident shows that a bridge can be hacked without there necessarily being a bug in the on-chain contract.

Smart contracts, meanwhile, form the on-chain rules of many bridges. They check signatures or cryptographic proofs, for example, and then carry out actions such as minting, burning, locking, or releasing tokens. If those checks are designed or implemented incorrectly, an attacker can sometimes create tokens or withdraw reserves without a valid underlying transaction.

Good protection therefore requires both secure smart contracts and strong key management.

What Are the Consequences of a Cross-Chain Bridge Exploit?

A cross-chain bridge exploit can cause reserves to disappear, liquidity pools to run dry, or wrapped tokens to no longer be fully backed.

That last point can have major consequences. In a lock-and-mint bridge, a wrapped token is normally backed by reserves on another blockchain. If that collateral disappears, the ability to redeem the wrapped token for the original asset can come under pressure. That can also affect protocols where the token is used as collateral, a trading asset, or liquidity.

Project teams can sometimes pause a bridge temporarily to limit further damage. After the Nomad exploit in August 2022, for example, further processing was stopped after a bug in initialization allowed invalid messages to be treated as valid. About $190 million in assets were taken from the bridge in that incident.

In the BNB Token Hub exploit in October 2022, a forged cryptographic proof was used, which allowed about 2 million extra BNB to be created. BNB Chain coordinated with validators to temporarily stop the blockchain and limit further damage. As a result, a large part of the BNB involved remained under control.

Blockchain transactions usually cannot simply be reversed by a central party the way a traditional bank transfer can. Still, that does not mean nothing can ever be done. Depending on the network, validators, project teams, token issuers, or governance can sometimes take steps to stop further transactions, freeze assets, or carry out other recovery measures.

A temporary pause can limit further damage, but it also has downsides. Users may temporarily not be able to bridge or withdraw their tokens. In addition, an emergency stop means certain administrators, validators, or guardians have influence over whether parts of the system can be slowed down or shut off.

Whether users are reimbursed after an exploit is not guaranteed. That depends, among other things, on available reserves, insurance, project decisions, governance, and whether stolen funds can be recovered.

A major bridge exploit can also hurt trust in a project or bridged asset. That can affect liquidity and possibly the market price too, but the effect differs by incident and market conditions.

Besides the direct financial loss, a bridge can therefore become less useful for a long time. Liquidity can drop, wrapped tokens can become harder to redeem, and users may be less willing to use the bridge again.

What Well-Known Cross-Chain Bridge Exploits Have There Been?

There have been several major bridge exploits. The technical cause differed from incident to incident.

• Poly Network: in August 2021, more than $600 million in crypto was moved through Poly Network by abusing the cross-chain infrastructure. A large part of the funds was later returned.
• Wormhole: in February 2022, a vulnerability in Wormhole on Solana was abused to create wrapped ETH without the required underlying backing. The attacker then moved part of the assets to Ethereum.
• Ronin Bridge: in March 2022, validator keys were compromised, allowing the attacker to approve unauthorized withdrawals. In total, 173,600 ETH and 25.5 million USDC were taken from the bridge.
• Harmony Horizon Bridge: in June 2022, at least two private keys of bridge validators were compromised. About $100 million in crypto was stolen in the incident.
• Nomad: in August 2022, a bug around initialization of the Replica contract caused unproven messages to be treated as valid. As a result, different addresses could copy transactions and take assets from the bridge. The total loss was about $190 million.
• BNB Chain Token Hub: in October 2022, the native bridge between BNB Beacon Chain and BNB Smart Chain was hit. By forging a low-level proof, about 2 million extra BNB could be created.

The amounts in such incidents do need context, though. A stated amount can refer to the market value of minted tokens, reserves actually taken, assets temporarily frozen, or amounts later recovered. Because crypto prices move, the reported dollar value can also differ depending on the measurement time.

How Can Cross-Chain Bridge Exploits Be Prevented?

Cross-chain bridge exploits cannot be fully prevented, but several independent security layers can reduce the chance of a successful attack and limit the maximum damage.

The foundation is strict verification. A bridge should, among other things, check where a message came from, whether it is valid, what action it is meant for, and whether it has already been used. Only then may a contract, for example, mint tokens or release reserves.

The trust model also matters. A bridge that depends on a small external validator or multisig set has a different risk profile than a bridge that verifies cross-chain information through, for example, light clients. No design is completely risk-free.

Other measures can help limit the maximum damage:

• Rate limits limit how much value can be moved within a certain period.
• Withdrawal caps set a maximum for payouts.
• Circuit breakers can automatically slow down or stop unusual activity.
• Pause functions can temporarily stop certain bridge activities during an incident.
• Monitoring can spot unusually large or unusual bridge messages faster.

Such an emergency brake does not fix the underlying vulnerability. It can, however, prevent an attacker from draining all available reserves in a short time.

Audits, bug bounties, code reviews, and extensive testing are also important. They work best together with continuous monitoring, secure key management, and an incident plan that has been prepared in advance.

What Security Measures Can Developers Take?

Developers can reduce risk by setting up verification, access rights, key management, and emergency measures strictly from the start.

1. Check every message fully. Check the source blockchain, sender, nonce or unique message ID, destination, and allowed function, among other things. That helps prevent a message from the wrong source or one reused for a different action.

2. Build in replay protection. Mark a processed message as used and do not accept it again. This helps against replay attacks, where the same instruction is executed multiple times.

3. Give out as few rights as possible. Use the principle of least privilege. Not every account needs to be able to upgrade contracts, change validators, mint tokens, or trigger an emergency stop. The fewer permissions one account has, the smaller the potential damage if it is compromised.

4. Protect admin accounts with a multisig. For sensitive admin actions, use multiple independent signers where appropriate instead of one externally owned account with one private key. A multisig is only useful if the signers and their keys are actually sufficiently independent.

5. Use a timelock for risky changes. A timelock builds in a waiting period before an upgrade or governance decision is executed. That way, changes can be checked in advance and suspicious activity can be noticed earlier.

6. Test more than just the normal path. Have independent audits performed, but also test upgrades, initialization, bad input, edge cases, and proof verification. The Nomad exploit shows how serious a bug during an upgrade or initialization can be.

7. Prepare incident response in advance. Use monitoring, anomaly detection, rate limits, and, where appropriate, a controlled emergency stop. Decide in advance who may step in, what actions are possible, and how communication will happen during an incident.

8. Handle private keys carefully. Keep validator and admin keys separate and well protected. Also make sure there are procedures for adding, removing, and replacing signers in a controlled way.

An audit or bug bounty is not a security seal. New upgrades, off-chain relayers, configuration changes, and the day-to-day security of private keys remain separate risks.

How Can Users Reduce Risk?

As a user, you cannot control a bridge's security yourself, but you can limit how much risk you take on through a bridge.

1. Look at the trust model. Check which bridge you are using and how cross-chain messages are verified. For example, see whether it uses an external validator group, multisig, light client, or another verification model.

2. Use the right interface. Open the bridge through a trusted and verified project channel. Before you sign a transaction, check the URL, blockchain, receiving address, and token you are sending.

3. Do not sign blindly. Check what a transaction or message does before you sign it. Blind signing can expose you to phishing, a malicious contract, or unwanted approvals.

4. Limit token approvals. Where possible, approve only the amount needed. A token approval can stay active on-chain until it is changed or revoked.

5. Revoke unused approvals. Check old spending caps and revoke them if you no longer need them. Simply disconnecting your crypto wallet from a dApp does not remove existing token approvals.

6. Limit your exposure. A small test transaction can help you check, for example, the address, interface, and chosen route. But such a test does not prove that the bridge itself is safe.

7. Keep the risk of bridged tokens in mind. After an exploit, wrapped tokens can temporarily become harder to redeem or less liquid. The longer and the more value depends on one bridge's underlying reserves, the greater the exposure to that specific bridge risk.

Also check current official incident reports and security warnings before using a bridge.

Conclusion

A cross-chain bridge makes it possible to exchange tokens, messages, and other data between blockchains, but it also adds an extra security layer. Vulnerabilities can arise, among other places, in cross-chain message verification, access rights, private keys, configuration, and smart contracts.

The consequences can be major because bridges often manage large amounts of crypto or are responsible for backing wrapped tokens. Incidents at Poly Network, Wormhole, Ronin, Harmony, Nomad, and BNB Chain, among others, also show that bridge exploits can happen in very different ways.

For developers, good security therefore comes down to multiple independent layers: strict verification, replay protection, limited admin rights, secure key management, monitoring, and a prepared incident plan. For users, the main thing is to understand what trust model a bridge uses, check the right interface, and keep the extra risks of bridged assets in mind.

Bridges play an important role in a multi-blockchain ecosystem, but they are not risk-free. The better you understand how a bridge checks events on another blockchain and which parties or systems that verification depends on, the better you can judge its security model.