Ronin Bridge

In withdrawERC20For and withdrawERC721For, the withdrawal state (_insertWithdrawalEntry) is recorded AFTER external token transfers. An attacker receiving tokens via a callback hook (ERC777 tokensReceived) can re-enter the same withdrawal function with identical parameters. Since the onlyNewWithdrawal check passes (state not yet updated), the withdrawal executes again, draining the gateway.

Complete loss of deposited funds. An attacker with valid validator signatures for a single withdrawal can re-enter repeatedly to drain the entire gateway balance of the target token.

Move _insertWithdrawalEntry before all external calls in both withdrawERC20For and withdrawERC721For to follow checks-effects-interactions pattern.

Both withdrawERC20For and withdrawERC721For record the withdrawal entry (the replay-prevention mechanism) AFTER transferring tokens to the user via external calls. An attacker receiving a callback-capable token (ERC777 tokensReceived hook, or ERC721 onERC721Received) can re-enter the withdrawal function with the same withdrawalId and signatures before the entry is written. The onlyNewWithdrawal check passes on re-entry because the entry does not yet exist, allowing multiple withdrawals from a single valid signature set.

Complete drainage of bridge funds for the targeted token. An attacker with one valid set of withdrawal signatures can withdraw the same amount repeatedly until the gateway is empty. Given bridge gateways typically hold all deposited mainchain assets, this represents catastrophic loss of funds.

Move _insertWithdrawalEntry before all external calls in both withdrawERC20For and withdrawERC721For to follow the checks-effects-interactions pattern.

In withdrawERC20For and withdrawERC721For, the withdrawal replay protection (_insertWithdrawalEntry) is performed after the external token transfer. Since onlyNewWithdrawal checks owner == address(0), a reentrant call with the same withdrawalId passes the check before the entry is written. Any mapped ERC20 token with transfer hooks (ERC777) allows the recipient to re-enter and execute the same withdrawal repeatedly, draining the gateway.

Complete drainage of any mapped ERC20 token balance from the gateway. All deposited user funds for the affected token are at risk. Attacker only needs one valid set of validator signatures.

Move _insertWithdrawalEntry before all external calls in both withdrawERC20For and withdrawERC721For to follow the checks-effects-interactions pattern.

The withdrawal signature hashes in withdrawERC20For and withdrawERC721For do not include address(this). Signatures are computed as keccak256(abi.encodePacked(‘withdrawERC20’, _withdrawalId, _user, _token, _amount)) without binding to the specific gateway deployment. If the gateway is redeployed or if the same validator set is used on another deployment, all historical withdrawal signatures can be replayed against the new contract.

All past withdrawal signatures become valid against any new gateway deployment sharing the same validator set. An attacker can extract signatures from on-chain transaction data and replay them to drain a redeployed gateway.

Include address(this) in both ERC20 and ERC721 withdrawal signature hashes.

The withdrawal signature hash is computed as keccak256(abi.encodePacked(‘withdrawERC20’, _withdrawalId, _user, _token, _amount)) without including block.chainid or address(this). This means valid withdrawal signatures are not bound to a specific chain or contract deployment. After an Ethereum hard fork, or if the gateway is redeployed, the same signatures can be replayed to execute unauthorized withdrawals.

Cross-chain signature replay after forks (e.g., ETH/ETC split) could drain the gateway on the forked chain. Cross-deployment replay could drain a redeployed gateway if the validator set remains the same.

Include chainId and address(this) in the signature hash for both withdrawERC20For and withdrawERC721For. Add a getChainId helper function.

Withdrawal signature hashes use keccak256(abi.encodePacked(‘withdrawERC20’, _withdrawalId, _user, _token, _amount)) without including block.chainid or address(this). For a cross-chain bridge deployed on multiple EVM chains with overlapping validator sets, valid withdrawal signatures from one chain can be replayed on another chain to double-withdraw funds.

Double-withdrawal across chains. Attacker who obtains a valid withdrawal signature on Chain A can replay it on Chain B, draining bridge funds on the target chain.

Include address(this) and the chain ID in all withdrawal signature hashes. Since block.chainid is not available in Solidity 0.5.x, store the chain ID at construction time using assembly.

depositERC20For records the caller-specified _amount as the deposited value without verifying the actual tokens received. If a mapped token charges a fee on transfer, the gateway receives fewer tokens than recorded, creating a growing insolvency that prevents later withdrawers from receiving their full amounts.

Gateway token balance becomes less than the sum of recorded deposits. Cumulative deficit grows with each deposit. Last users to withdraw cannot get their funds.

Measure the actual balance change by reading balanceOf before and after the transferFrom call.