A potential re-entrancy vulnerability exists in the withdraw function of the TokenManager.sol contract. This vulnerability can be exploited by malicious actors to withdraw more funds than they are entitled to, leading to significant financial loss.
The vulnerability is located in the following block of code within the withdraw function:
The issue arises because the contract transfers Ether to the caller (msg.sender) before updating the state to reflect the withdrawal. An attacker could exploit this by re-entering the withdraw function before the state is updated, allowing them to withdraw more funds than they are entitled to.
Initial State:
userTokenBalanceMap[attacker][wrappedNativeToken][balanceType] = 10 ETH
Attack Execution:
The attacker calls the withdraw
function to withdraw 10 ETH.
The contract transfers 10 ETH to the attacker.
Before the state is updated, the attacker re-enters the withdraw
function.
The contract transfers another 10 ETH to the attacker.
This process can be repeated multiple times, draining the contract's funds.
attackers can withdraw more funds than they are entitled to
To mitigate this vulnerability, follow the Checks-Effects-Interactions pattern. Update the state before transferring funds to prevent re-entrancy attacks
Valid critical severity finding, the lack of clearance of the `userTokenBalanceMap` mapping allows complete draining of the CapitalPool contract. Note: This would require the approval issues highlighted in other issues to be fixed first (i.e. wrong approval address within `_transfer` and lack of approvals within `_safe_transfer_from` during ERC20 withdrawals)
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.