You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue: The function calls external token contracts (IERC20.safeTransfer and IERC20.safeTransferFrom) which could re-enter the contract if exploited through a malicious token contract or unexpected behavior.
Impact: Internal state variables (e.g., vaultProfit, receivedNuma, etc.) could be manipulated, leading to inaccurate liquidation outcomes or loss of funds.
Conditions: Exploitation requires a malicious token contract or another external contract capable of re-entering during execution.
Severity
High
The reentrancy vulnerability can lead to unexpected behavior in the liquidation process, potentially draining liquidity from the contract, manipulating the liquidation amount, or altering the balance of assets inappropriately.
Deploy a malicious ERC20 contract that implements a re-entrant transfer or transferFrom function.
Trigger liquidateLstBorrower with this malicious token as input.
The malicious token contract re-enters the function, disrupting its execution and potentially modifying profits or vault balances.
Recommendations
Add Re-entrancy Guard:
Utilize OpenZeppelin's ReentrancyGuard library and apply the nonReentrant modifier to the liquidateLstBorrower function.
Brave Plum Shetland
High
Potential Re-entrancy Risk in Liquidation Function in NumaVault.sol
Summary
https://github.com/sherlock-audit/2024-12-numa-audit/blob/main/Numa/contracts/NumaProtocol/NumaVault.sol#L1113-L1229
The liquidateLstBorrower function in the smart contract is vulnerable to a potential re-entrancy attack due to external token transfers. Without a nonReentrant guard, the function could be exploited to disrupt its internal state during execution, particularly when transferring tokens or calling other contracts.
Vulnerability Details
Issue: The function calls external token contracts (IERC20.safeTransfer and IERC20.safeTransferFrom) which could re-enter the contract if exploited through a malicious token contract or unexpected behavior.
Impact: Internal state variables (e.g., vaultProfit, receivedNuma, etc.) could be manipulated, leading to inaccurate liquidation outcomes or loss of funds.
Conditions: Exploitation requires a malicious token contract or another external contract capable of re-entering during execution.
Severity
High
The reentrancy vulnerability can lead to unexpected behavior in the liquidation process, potentially draining liquidity from the contract, manipulating the liquidation amount, or altering the balance of assets inappropriately.
Likelihood
Moderate to High
Impact
High
Proof of Concept (PoC)
Deploy a malicious ERC20 contract that implements a re-entrant transfer or transferFrom function.
Trigger liquidateLstBorrower with this malicious token as input.
The malicious token contract re-enters the function, disrupting its execution and potentially modifying profits or vault balances.
Recommendations
Add Re-entrancy Guard:
Utilize OpenZeppelin's ReentrancyGuard library and apply the nonReentrant modifier to the liquidateLstBorrower function.
The text was updated successfully, but these errors were encountered: