Seven Key Cross-Chain Bridge Vulnerabilities Explained
A cross-chain vulnerability is a security flaw that can be exploited to steal or manipulate assets on a cross-chain bridge.
To date, cross-chain bridges have been hacked for more than $2.8 billion—representing almost 40% of the entire value hacked in Web3, according to DefiLlama.
While it’s undeniable that cross-chain is critical for unlocking exponential innovation in Web3, it also introduces a potential attack vector for malicious actors. In the software industry, many developers subscribe to the motto “move fast and break things.” But when it comes to cross-chain security and the safety of billions—and eventually trillions—in user funds, the opposite is true: If you move too fast, things break.
What Are Cross-Chain Bridges?
Cross-chain bridges are a type of decentralized application that facilitates the transfer of assets from one blockchain to another.
Today, cross-chain bridges vary significantly in design and purpose. Some bridges, for example, are specifically built to facilitate transfers between a layer 2 and its respective base chain. General-purpose bridges, such as the ones built on top of Chainlink CCIP, are built to enable seamless asset and message transfers between a wide variety of blockchains.
Cross-chain bridges are a core piece of Web3 infrastructure. For users, cross-chain bridges enable seamless movements of tokens and messages between chains. For developers, cross-chain protocols represent an opportunity to build chain-agnostic experiences that abstract away infrastructural complexities. And with 6B+ in monthly volume across all cross-chain bridges, it’s clear that cross-chain is a necessary—and widely adopted—part of the Web3 ecosystem.
That’s why if you’re a user, developer, or institution looking to go cross-chain, it’s imperative that you understand these seven key cross-chain bridge vulnerabilities to keep yourself, your users, and your stakeholders secure.
1. Unsecure Private Key Management
Private keys—or a set of private keys—are often what manage a cross-chain bridge’s operations. The bridge operator or operators who individually hold a unique private key are tasked with coming to consensus and confirming the message or value being sent cross-chain by a user and delivering it accurately across chains. These messages are approved based on a digital signature, or a quorum of digital signatures, which are derived from the underlying private keys.
Thus, private key compromises are one of the most common vulnerabilities for a cross-chain bridge, the culprit behind some of Web3’s most notorious cross-chain bridge hacks, often due to poor private key management or operational security practices.
A general rule of thumb is that the more servers, infrastructure providers, locations, and operators, the more a cross-chain bridge and the private keys securing it are protected against single points of failure and centralization risks.
Chainlink CCIP mitigates the extent of a potential private key compromise by using multiple decentralized oracle networks (DONs) per CCIP lane, powered by highly reputable and geographically distributed node operators, and supported by a first-of-its-kind independent Risk Management Network that can temporarily halt cross-chain activity if erroneous activity is detected. Due to this defense-in-depth security architecture, even if multiple private keys are compromised, CCIP’s multiple layers of decentralization and redundancy provide robust protection against attacks.
Decentralization helps mitigate centralization risks, which protects against the possibility of both internal and external attacks by requiring any malicious actor (even a bridge operator) to compromise the private key of multiple independent entities. It is a powerful form of security. However, it is only one consideration among many for secure private key management. Equally important are the security measures that bridge operators independently take to secure their private keys.
Best Practices
Decentralization is important for providing security against single points of failure, but private key security isn’t monolithic—the most secure cross-chain protocols combine the security that decentralization provides with time-tested methods of securing individual private keys. These include hardware security modules (HSMs), encryption (in transit, at rest), phishing education, access controls, key management services, and more.
Notable Real-World Cross-Chain Bridge Exploits Due to Compromised Private Keys
- Ronin Bridge (March 2022)—Five out of nine private keys needed to facilitate, approve, and execute transactions on the Ronin Bridge multisig were compromised.
- Harmony Bridge (June 2022)—Two out of the five private keys needed to facilitate, approve, and execute transactions on the Harmony Bridge multisig were compromised.
- Multichain Bridge Hack (July 2023)—The cross-chain bridge’s compromised private keys, which led to unauthorized withdrawals, were all under the control of Multichain’s CEO.
- Orbit Chain (January 2024)—Seven out of ten of the bridge’s multisig private keys were compromised, enabling attackers to drain funds.
- ALEX bridge (May 2024)—Following a contract upgrade by the protocol’s deployer account, ALEX suffered $4.3 million in suspicious withdrawals, with security company CertiK referring to the incident as a “possible private key compromise”.
2. Unaudited Smart Contracts
Because the primary function of cross-chain bridges is to move value from one blockchain to another, it’s inevitable that all cross-chain protocols must deal with smart contracts.
In the vast majority of cross-chain use cases, smart contracts on multiple chains are leveraged to power the minting, burning, locking, or unlocking of tokens as they move across chains. These smart contracts are connected through cross-chain bridges, often in collaboration with token issuers.
Smart contracts are both an additional line of defense against exploits and a technical risk when constructed incorrectly. On one hand, smart contracts provide a valuable avenue for cross-chain bridges to enforce various common sense security checks, such as ensuring that a user cannot withdraw more than they have deposited and rate limiting. On the other hand, poorly written and unaudited smart contract code can have the exact opposite effect: Malicious hackers have exploited flaws in smart contract code to hack enormous amounts from cross-chain bridges.
It’s impossible for any project—no matter how security-sensitive it is—to guarantee that there are no technical bugs in its smart contracts’ code. However, one of the most battle-tested methods of ensuring solid, exploit-resistant code is to work with external, experienced auditors to battle-test a codebase before it is deployed in production. This is not a one-and-done initiative—even the most well-constructed codebases immediately become untested if code is changed after an audit or if unaudited contracts are introduced to an audited codebase.
Best Practices
Smart contract risk is very real when using a cross-chain protocol. The most secure cross-chain bridges continuously put their codebase to the test multiple times across both private audits and competitive audits, as well as a variety of internal security testing such as fuzz testing, static analysis, formal verification, symbolic execution, and more.
Checking to see how many times the codebase has been audited, and by whom, serves as a reliable signal that the cross-chain bridge being used is protected against technical exploits. Additionally, layered security, such as enabling emergency pauses and updates, as well as implementing rate limits, can mitigate the impact of any smart contract bug.
Real-World Cross-Chain Bridge Exploits Due to Smart Contract Risk
- Qubit (January 2022)—A logic error in the bridge’s code allowed an attacker to withdraw tokens on BNB Chain when none were deposited on Ethereum.
- Meter.io (February 2022)—A faulty assumption regarding deposits of wrapped native tokens allowed an attacker to withdraw native tokens without any matching deposits.
- Wormhole Bridge (February 2022)—The verification steps outlined in the bridge’s smart contract were exploited to mint 120,000 wETH on Solana without the appropriate collateralization.
- Nomad Bridge (August 2022)—A mistakenly implemented default accepted root (0x00) in the bridge’s smart contract enabled anyone to drain funds from the bridge.
- Binance Bridge (October 2022)—A flaw in the IAVL Merkle proof verification system, implemented within the bridge’s smart contract, was exploited. This resulted in 2M BNB being transferred from the bridge to the exploiter.
- Socket Interoperability Protocol (January 2024)—A flaw in the protocol’s smart contracts affected wallets with infinite approvals to Socket’s smart contracts.
3. Unsafe Upgradability Processes
Upgradability refers to the ability to update a smart contract’s code, or change certain parameter configurations within the contract’s code.
Developers often use upgradable contracts to update their smart contracts in order to add new features, address contract logic errors, and modify key risk parameters. In the context of cross-chain bridges, this allows for the ability to add support for new tokens and blockchains, implement new methods of validating cross-chain messages based on new technologies, adjust key risk parameters like rate limits and node composition, as well as swiftly address any unforeseen logic errors in the underlying smart contracts.
Upgradability is important in a security context because if the upgrade process is not secure, it can introduce a potential attack vector. Secure upgradability with cross-chain bridges means taking a defense-in-depth approach, which includes robust private key management with keys held by multiple independent entities, timelock delays to allow users to inspect on-chain changes before they take effect, as well as robust approval processes such as the ability for cross-chain bridge operators to veto changes proposed in the timelock. To account for situations where an upgrade needs to be applied swiftly, explicit approval can be provided by the bridge operators after reviewing the changes.
Best Practices
Upgradability is key to staying adaptable and accounting for unknown unknowns, but the upgradability process can be another vulnerability for cross-chain protocols if implemented incorrectly. Timelock contracts and node-veto mechanisms are important tools for hardening the upgradability process, but secure cross-chain bridges must also balance the need to provide an alternative path during time-sensitive circumstances, all while maintaining the highest standards of security.
4. Single Network Dependency
Some cross-chain bridges rely on a single network of validators for all bridging operations. While this may work for bridges purpose-built to facilitate transactions between two specific blockchains, it is not a secure or scalable solution for general-purpose bridges that aim to seamlessly connect the disparate multi-chain world we live in today.
The most important reason to avoid bridges with this architecture is the disproportionate impact a bridge hack or exploit would have on users. Because all of the cross-chain transactions and the value associated with them are facilitated by a single monolithic network, any successful breach would result in a wide and comprehensive exploit of the bridge across all blockchains—with little to no separated risk.
A more secure (and scalable) design is an independent, multi-network design, which means:
- Cross-chain lanes are operated by an independent, decentralized network. This means that there is an independent, decentralized network for each lane between blockchains (i.e., blockchain A to blockchain B is a single lane). This mitigates the risk that the impact of a single exploit will spread past its particular lane.
- Each cross-chain lane is secured by multiple networks. As an additional level of redundancy, the most secure cross-chain bridges and protocols leverage multiple networks for each specific lane. This provides an extra layer of security for each cross-chain lane by requiring a malicious actor to compromise multiple networks simultaneously to successfully execute a hack or exploit.
Best Practices
Implementing multiple independent and decentralized networks for each cross-chain lane drastically reduces the attack surface and incentive for a malicious actor. Best-in-class implementations of this approach also include leveraging different coding languages for client diversity, separating responsibilities between networks with non-overlapping validator sets, and adding active risk management capabilities.
5. Unproven Validator Sets
The heart of any cross-chain bridge is its operators—the people and organizations responsible for maintaining the infrastructure that runs the cross-chain bridge’s operations.
Users, institutions, and dApp developers should be wary of unproven validator sets that lack the requisite experience and knowledge to securely and reliably operate a cross-chain bridge. A maximum-security cross-chain bridge requires world-class validator sets that all have extensive experience in operational security (OPSEC) to ensure proper private key management and reliable cross-chain transaction processing and execution.
The second point is largely overlooked by today’s users, devs, and institutions. A key risk for any cross-chain bridge user in regard to the underlying validator sets is that the validator set will not reliably execute transactions. For example, a user could lock up funds on one chain expecting a corresponding mint on another blockchain, but if the validator set is offline and does not approve the mint, it effectively freezes the user’s funds.
Best Practices
Cross-chain bridges should use only high-quality validators with a proven history of OPSEC experience, excellence, and rigor. Because OPSEC skills are not necessarily Web3-exclusive, this can include a variety of validators across both Web2 and Web3, but it’s always critical to verify the past performance of any cross-chain bridge validator. Additionally, adding economic security by requiring validators to put up collateral (stake) that is slashed in cases of misbehavior or unreliable operation can add additional incentives for validators to act honestly and reliably.
6. No Active Transaction Monitoring
The goal of active transaction monitoring is to detect and react to anomalous behavior of a cross-chain bridge in real-time. When implemented properly, active transaction monitoring acts as a robust tool for detecting anomalous activity and immediately taking the necessary preventative measures to avoid a hack or exploit.
A key example and use case for active transaction monitoring is for emergency pauses of the cross-chain system before executing anomalous transactions, or after a malicious transaction has bypassed the system, such as a successful request to withdraw a cross-chain bridge’s entire asset pool without the required collateral. For example, in CCIP’s case, the Risk Management Network observes whether tokens on the source chain are properly committed prior to tokens on the destination chain being released or minted. If an anomaly is detected, the Risk Management Network can temporarily halt CCIP activity.
Real-World Cross-Chain Bridge Exploits Due to No Active Transaction Monitoring
- Ronin Bridge (March 2022)—According to Halborn Blockchain Security, the Ronin Bridge hack was detected six days after it happened, an important blind spot that could have been addressed by active transaction monitoring.
Best Practices
Active transaction monitoring should generally be performed by a separate entity or network from the cross-chain bridge’s primary validator set. This helps separate responsibilities and creates a checks-and-balances situation that reduces the possibility that a malicious operator, or operator set, can manipulate the real-time responses active transaction monitoring may trigger.
7. Lack of Rate Limits
Rate limits are not a new idea. In traditional software, rate limits are a security measure used by websites to prevent denial-of-service (DOS) attacks and by data providers to stop an overwhelming number of API requests from shutting down their servers.
The concept is quite simple: Limit the number of requests that can be made by both time and volume. What kind of requests? In the cross-chain world, rate limits put a cap on the amount of value that can be transferred between chains within a given time span.
This simple security measure is a powerful last line of defense for a cross-chain bridge. Even in the event of a successful hack or exploit that evades every other security measure, rate limits put a limit on how much value can actually be extracted from the cross-chain bridge.
Real-World Cross-Chain Bridge Exploits Due to Lack of Rack Limits
- Every single bridge hack in which all of the value was stolen in a short time frame could have been mitigated by rate limits and an emergency halt functionality, assuming there were no logic errors in its implementation.
Best Practices
Rate limits for assets should be determined on a per-lane basis for maximum security and modularity. Additionally, each lane should have an aggregate rate limit to limit the overall value that can be transferred on that lane across all assets. Implementing well-defined throughput rates (i.e., X tokens every 10 minutes max) can help prevent malicious actors from draining all assets within a bridge in a single transaction. “Refill rates” can also be applied to various cross-chain assets and lanes to avoid situations where malicious actors wait for a rate limit to reset to steal the maximum amount possible.
Chainlink CCIP Provides Unmatched Cross-Chain Security
One key takeaway should be that cross-chain security is not as straightforward as implementing a single security measure. In reality, a robust cross-chain security design requires a defense-in-depth implementation that layers different security measures together to provide broad-spectrum protection against a hack or exploit.
That’s exactly how Chainlink CCIP—the industry-standard cross-chain solution—has been architected.
Read more:
