Bridge and cross-chain vulnerabilities in disclosed reports
Bridges hold concentrated value and validate messages produced on a chain they cannot themselves verify — the highest-severity surface in the space.
- Reports indexed
- 54
- Total paid
- $1.8M
- Critical
- 1
- Largest payout
- $1.8M
A bridge is a message verifier attached to a vault. Everything that has gone wrong with bridges is one of those two halves failing: the verifier accepts a message it should not have, or the vault releases funds the verifier never authorised.
The verifier failures are the interesting ones. Merkle proofs validated against an attacker-supplied root, signature thresholds counted without deduplicating signers, guardian sets rotated without invalidating the old set, and message handlers that check the payload but not the source chain or the source contract.
The vault failures tend to be simpler and just as expensive: mint functions reachable without a corresponding lock, replay protection keyed on a value the attacker chooses, and emergency withdrawal paths whose access control was never revisited after launch.
What reviewers look for
- Proof verification against a root the caller can influence
- Signature thresholds that do not deduplicate or order signers
- Message IDs that are not globally unique across chains
- Mint authority reachable without a verified lock event
- Guardian or validator rotation that leaves the previous set valid
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Bridge withdrawal proof accepts empty Merkle path
A flawed proof verification mechanism in an L2 canonical bridge contract permitted withdrawal validation using an empty Merkle proof array. When no proof elements were supplied, the verification function failed to iterate and directly compared the unhashed withdrawal leaf against the target root. By matching a fake withdrawal leaf payload with a valid historical or relayable state root, an attacker could forge arbitrary withdrawal events and drain escrowed funds from the bridge.
Olas: Users will lose all ETH sent as `cost` parameter in transactions to and from Optimism
The Olas protocol's OptimismDepositProcessorL1 contract mistakenly attempts to cover message delivery fees by forwarding ETH as a value to the Optimism messaging bridge. This design is incompatible with the Optimism protocol, which covers message delivery through gas consumption on the source chain rather than explicit ETH transfers to the messenger. As a result, any funds users provide to cover these expected costs are erroneously sent to the L2 destination contract, where they remain permanently locked and inaccessible to the user.
Olas: Attacker can make claimed staking incentives irredeemable on Gnosis Chain
The Olas staking incentive bridge on Gnosis Chain is vulnerable to a denial-of-service attack due to improper validation of user-supplied gas limits for cross-chain messages. By specifying an intentionally low gas limit during the claim process, an attacker can cause the L2 execution of the bridge message to fail with an out-of-gas error. Since the Gnosis Arbitrary Message Bridge does not natively support message replays, this renders the claimed incentives permanently irredeemable without costly, off-chain governance intervention.
Olas: Refunds for unconsumed gas will be lost due to incorrect refund chain ID
The Olas `WormholeDepositProcessorL1` contract contains a logic error in its interaction with the Wormhole bridge SDK that leads to the loss of user gas refunds. When initiating cross-chain transfers, the contract provides an incorrect chain identifier for the gas refund mechanism, substituting a local EVM chain ID where a Wormhole-specific chain ID is required. This misconfiguration causes any unconsumed gas associated with the transfer to be sent to the wrong network or permanently lost, negatively impacting the cost-efficiency for users utilizing the staking incentive features.
Olas: Loss of incentives if total weight in an epoch is zero
The Olas protocol's `Dispenser.sol` contract contains a critical accounting flaw that causes staking incentives to be permanently lost if an epoch records zero total staking weight. Because the incentive refund logic is incorrectly dependent on the claimant's staking weight, epochs with no activity fail to trigger a refund of the allocated tokens back to the inflation pool. This results in these unclaimed incentives remaining permanently trapped within the contract, rather than being returned to the tokenomics system as intended.
Arbitrum Foundation: Inconsistent sequencer unexpected delay in DelayBuffer may harm users calling `forceInclusion()`
Arbitrum's DelayBuffer, which determines how long users must wait before force-including delayed messages when the sequencer is down, depletes non-deterministically depending on how delayed messages are batched into forceInclusion() calls. Because the buffer decrease subtracts the last sequenced block number from the previous buffer-update block number, force-including multiple messages at once (or a newer one first) leaves the buffer larger than if messages were included sequentially in oldest-first order. As a result a user's later message can remain blocked far longer than the intended delay, locking funds for an extended period after a sequencer outage. The finding was disputed by the sponsor as by-design but ultimately accepted as Medium by the judge on availability grounds.
All reports in this group
- Taiko: A recalled ERC20 bridge transfer can lock tokens in the bridgeBridge exploit$0
- Taiko: Bridged tokens would be lost if sender and receiver are contracts that don't implement fallback/receiveBridge exploit$0
- Taiko: Malicious caller of `processMessage()` can pocket the fee while forcing `excessivelySafeCall()` to failBridge exploit$0
- Decent: Permanent loss of tokens if swap data gets outdatedBridge exploit$0
- Decent: Potential loss of capital due to fixed fee calculationsBridge exploit$0
- Decent: Due to missing checks on minimum gas passed through LayerZero, executions can fail on the destination chainBridge exploit$0
- Decent: DecentEthRouter.sol#_bridgeWithPayload() - Any refunded ETH (native token) will be refunded to the DecentBridgeAdapter, making them stuckBridge exploit$0
- zkSync: `Mailbox.requestL2Transaction()` checks the deposit limit of `msg.sender` (`L1WethBridge`) instead of the real depositor of weth from L1, as a result, after certain time, nobody will be able to deposit weth anymore from L1Bridge exploit$0
- Olas: Withdraw amount returned by `getLiquidityAmountsAndPositions` may be incorrectBridge exploit$0
- Maia DAO: If `RootBridgeAgent.lzReceiveNonBlocking` reverts internally, the native token sent by relayer to RootBridgeAgent is left in RootBridgeAgentBridge exploit$0
- Maia DAO: Incorrect flag results to `_hasFallbackToggled` always set to false on `createMultipleSettlement`.Bridge exploit$0
- Maia DAO: `addGlobalToken()` `localAdress` could be overwrittenBridge exploit$0
- Maia DAO: No deposit cross-chain calls/communication can still originate from a removed branch bridge agentBridge exploit$0
- Maia DAO: When using BaseBranchRouter as a router on the 'Arbitrum' branch, we are unable to invoke the 'callOutAndBridge' function.Bridge exploit$0
- Maia DAO: Message channels can be blocked resulting in DoSBridge exploit$0
- Maia DAO: `ArbitrumBranchBridgeAgent::_performFallbackCall` function does not refund users their excess native gas depositBridge exploit$0
- Maia DAO: `BaseBranchRouter._transferAndApproveToken` may revert in some casesBridge exploit$0
- Maia DAO: Depositors could lose all their deposited tokens (including the hTokens) if their address is blacklisted in one of all the deposited underlyingTokensBridge exploit$0
- Maia DAO: Redeeming a Settlement won't work for unsigned messages when the communicating dApps have different addresses on the different chainsBridge exploit$0
- Tapioca DAO: All assets of (m)TapiocaOFT can be stealed by depositing to strategy cross chain call with 1 amount but maximum shares possibleBridge exploit$0
- Tapioca DAO: TOFT `removeCollateral` can be used to steal all the balanceBridge exploit$0
- Tapioca DAO: `_sendToken` implementation in `Balancer.sol` is wrong which will make the underlying erc20 be send to a random address and lostBridge exploit$0
- Tapioca DAO: TOFT `triggerSendFrom` can be used to steal all the balanceBridge exploit$0
- Tapioca DAO: Attacker can block LayerZero channel due to missing check of minimum gas passedBridge exploit$0
- Tapioca DAO: Refund mechanism for failed cross-chain transactions does not workBridge exploit$0
- Tapioca DAO: Attacker can pass duplicated reward token addresses to steal the reward of contract `twTAP.sol`Bridge exploit$0
- Tapioca DAO: TOFT in (m)TapiocaOft contracts can be stolen by calling removeCollateral() with a malicious removeParams.marketBridge exploit$0
- Tapioca DAO: `multiHopSellCollateral()` will fail due to call on an invalid market address causing bridged collateral to be locked upBridge exploit$0
- Centrifuge: `onlyCentrifugeChainOrigin()` can't require `msg.sender` equal `axelarGateway`Bridge exploit$0
- Maia DAO Ecosystem: On Ulysses omnichain - `RetrieveDeposit` might never be able to trigger the `Fallback` functionBridge exploit$0
- Maia DAO Ecosystem: `RootBridgeAgent->CheckParamsLib#checkParams` does not check that `_dParams.token` is underlying of `_dParams.hToken`Bridge exploit$0
- Maia DAO Ecosystem: An attacker can steal Accumulated Awards from `RootBridgeAgent` by abusing `retrySettlement()`Bridge exploit$0
- Maia DAO Ecosystem: The user is enforced to overpay for the `fallback` gas when calling `retryDeposit`Bridge exploit$0
- Maia DAO Ecosystem: Cross-chain messaging via `Anycall` will failBridge exploit$0
- Maia DAO Ecosystem: Incorrectly reading the offset from the received data parameter to get the `depositNonce` in the `BranchBridgeAgent::anyFallback()` functionBridge exploit$0
- Maia DAO Ecosystem: `BranchBridgeAgent._normalizeDecimalsMultiple` will always revert because of the lack of allocating memoryBridge exploit$0
- Maia DAO Ecosystem: Inconsistencies in reading the encoded parameters received in the `_sParams` argument in `BranchBridgeAgent::clearTokens()`Bridge exploit$0
- Maia DAO Ecosystem: Multiple issues with decimal scaling will cause incorrect accounting of hTokens and underlying tokensBridge exploit$0
- Maia DAO Ecosystem: Depositing gas through `depositGasAnycallConfig` should not withdraw the `nativeToken`Bridge exploit$0
- Maia DAO Ecosystem: Accessing the incorrect offset to get the nonce when a flag is 0x06 in `RootBridgeAgent::anyExecute()` will lead to marked as executed incorrect nonces and could potentially cause a DoSBridge exploit$0
- Maia DAO Ecosystem: Incorrect accounting logic for `fallback` gas will lead to insolvencyBridge exploit$0
- Maia DAO Ecosystem: When the `anyExecute` call is made to `RootBridgeAgent` with a `depositNonce` that has been recorded in `executionHistory`, `initialGas` and `userFeeInfo` will not be updated, which would affect the next caller of `retrySettlement`.Bridge exploit$0
- Maia DAO Ecosystem: Replenishing gas is missing in `_payFallbackGas` of `RootBridgeAgent`Bridge exploit$0
- Maia DAO Ecosystem: Due to inadequate checks, an adversary can call `BranchBridgeAgent#retrieveDeposit` with an invalid `_depositNonce`, which would lead to a loss of other users' deposits.Bridge exploit$0
- Maia DAO Ecosystem: Lack of a return value handing in `ArbitrumBranchBridgeAgent._performCall()` could cause users' deposit to be locked in contractBridge exploit$0
- Maia DAO Ecosystem: Missing the unwrapping of native token in `RootBridgeAgent.sweep()` causes fees to be stuckBridge exploit$0
- Maia DAO Ecosystem: Multiple issues with `retrySettlement()` and `retrieveDeposit()` will cause loss of users' bridging depositsBridge exploit$0
- Maia DAO Ecosystem: User may underpay for the remote call `ExecutionGas` on the root chainBridge exploit$0