Navigating to H-01 from the previous contest we can see that there was a vulnerability in the WithdrawQueue.sol contract that allows users' funds to become permanently locked if they withdraw ezETH to a contract address (like a multisig wallet) that requires more than 2300 gas to process the receiving transaction.
This issue was caused by the previous use of payable(msg.sender).transfer(_withdrawRequest.amountToRedeem); to send the tokens. Now this issue has been sufficiently mitigated by using the call() function instead of transfer() when sending ETH during the claim process, as shown in the pull request used to solve this, i.e:
// send selected redeem asset to user
if (_withdrawRequest.collateralToken == IS_NATIVE) {
- payable(msg.sender).transfer(_withdrawRequest.amountToRedeem);
+ (bool success, ) = payable(msg.sender).call{ value: _withdrawRequest.amountToRedeem }(
+ ""
+ );
+ if (!success) revert TransferFailed();
} else {
IERC20(_withdrawRequest.collateralToken).transfer(
msg.sender,
Lines of code
Vulnerability details
See:
Navigating to H-01 from the previous contest we can see that there was a vulnerability in the
WithdrawQueue.sol
contract that allows users' funds to become permanently locked if they withdrawezETH
to a contract address (like a multisig wallet) that requires more than2300
gas to process the receiving transaction.This issue was caused by the previous use of
payable(msg.sender).transfer(_withdrawRequest.amountToRedeem);
to send the tokens. Now this issue has been sufficiently mitigated by using thecall()
function instead oftransfer()
when sending ETH during the claim process, as shown in the pull request used to solve this, i.e: