The _depositIntoEscrow
function is vulnerable to a reentrancy attack due to the lack of reentrancy protection. This flaw allows an attacker to exploit the function by calling it recursively during its execution, potentially withdrawing assets before the contract state is updated, leading to unauthorized access or double-spending of tokens.
The _depositIntoEscrow
function performs token transfers within a loop, depositing assets into escrow. However, the function does not implement any reentrancy guards. This omission means that during the execution of the function, particularly after the transferFrom
or safeTransferFrom
calls, an attacker could invoke another call to the function before the state is updated. By doing so, the attacker could repeatedly trigger the deposit process, manipulating the state to their advantage and potentially draining the escrow of assets.
Even though it don't directly effect the code , a successful reentrancy attack could allow an attacker to withdraw more tokens than they originally deposited, effectively draining the contract's funds. It is recommended to write code with a CEI(Checks Effects Interactions) Pattern always.
Manual Review.
Use OpenZeppelin's Reentrancy Guard.
Use Checks Effects Interactions Pattern in the codebase.
Impact: - NFT already bridged won’t be bridgeable anymore without being stuck. Likelyhood: Low. - Attackers will corrupt their own tokens, deploying a risky contract interacting with an upgradable proxy. They have to buy and sell them without real benefits, except being mean. Some really specific and rare scenario can also trigger that bug.
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.