Mezo L1 Bridge Vulnerability Leads to Potential ERC-20 Drain
A vulnerability in the Mezo bridge allows for the potential full drain of the L1 bridge without changing the bridged balance on Mezo due to a stale StateDB overwrite, enabling a malicious user to steal ERC-20 tokens locked in the L1 bridge.
A critical vulnerability in the Mezo bridge allows a malicious actor to potentially drain all ERC-20 tokens locked in the Layer 1 (L1) bridge without affecting the bridged balance on the Mezo network. This attack exploits an asymmetry in how the bridgeOut precompile handles BTC and ERC-20 tokens. The vulnerability exists because the outer StateDB overwrites the inner burn transaction with stale values. This restores the attacker’s balance and allowance while the AssetsUnlocked event has already been persisted to the bridge store. The Ethereum sidecar then observes this event, attests the unlock on L1, and releases real tokens to the attacker, who can repeat the drain every block. This issue was found in the Mezo EVM and impacts ERC-20 token bridging. The fixed version of the validator client has been deployed.
Attack Chain
- The attacker deploys a crafted contract on the Mezo network to interact with the
bridgeOutprecompile. - The attacker calls the
bridgeOutprecompile with an ERC-20 token, triggering theburnERC20function viaExecuteContractCall. This creates an inner StateDB where the token burn occurs. - Within the inner StateDB, the
burnFromfunction decreases the balance, supply, and allowance slots of the ERC-20 token. - The inner StateDB commits its changes to a cached context (
cachedCtx) but does not propagate these changes to the outer StateDB’sdirtyStorage. - The attacker triggers a
transfer(sink, 1)in the same transaction, causing the outer StateDB to load the stale pre-burn balance from the base context (baseCtx). - The outer StateDB’s
dirtyStoragenow contains the pre-burn allowance and stale balance, while theAssetsUnlockedEventhas been persisted to the bridge module’s KV store. - During the
StateDB.Commit()process, the stale allowance and balance slots indirtyStorageoverwrite the zeroed-out values from the inner burn, effectively erasing the burn. - The Ethereum sidecar observes the
AssetsUnlockedEventand callsAttestBridgeOuton the L1 MezoBridge contract, releasing real tokens to the attacker’s L1 address. The attacker repeats this process per block to drain the bridge.
Impact
This vulnerability poses a critical risk to the Mezo bridge, potentially leading to the theft of approximately $1,753,958.4 USD worth of assets held on the L1 bridge. Attackers can repeatedly exploit this vulnerability to drain ERC-20 tokens, including cbBTC, T, USDC, USDT, xSolvBTC, SolvBTC, FunctionBTC, USDe, swBTC, and DAI, without affecting their Mezo balance. This exploit threatens the integrity and trustworthiness of the Mezo bridge and the assets locked within it.
Recommendation
- Implement detection rules to identify transactions interacting with the
bridgeOutprecompile andExecuteContractCallthat do not properly propagate state changes to the outer StateDB. - Monitor Ethereum L1 MezoBridge contract (0xF6680EA3b480cA2b72D96ea13cCAF2cFd8e6908c) for unexpected or anomalous withdrawal patterns.
- Investigate all
AssetsUnlockedEventevents to validate that corresponding balance and allowance changes have been correctly applied within the Mezo network before attesting unlocks on L1 as described inx/bridge/keeper/assets_unlocked.go:104-163. - Enable logging of state changes within the EVM, particularly focusing on the
Commit()function atx/evm/statedb/statedb.go:677-684to detect potential stale overwrites.
Detection coverage 3
Monitor Mezo Bridge ERC-20 Burn Events
highDetects calls to the burnERC20 function within the Mezo bridge contract, which could indicate potential exploitation of the stale StateDB overwrite vulnerability.
Detect AssetsUnlocked Event on Mezo Bridge
mediumDetects the occurrence of the AssetsUnlocked event on the Mezo bridge contract, indicating a potential transfer of assets to L1. This rule helps monitor for unusual activity related to asset unlocks, especially when paired with other suspicious behaviors.
Detect Transfer After burnERC20 Within Same Transaction
highDetects a transfer function call occurring in the same transaction after burnERC20 is called. This will assist in identifying possible exploits.
Detection queries are kept inside the platform. Get full rules →