The depositEgg function in the EggVault contract is vulnerable to front-running attacks. An attacker can monitor the mempool for NFT transfers to the vault and front-run the legitimate user's depositEgg call, claiming ownership of the deposited NFT. This vulnerability arises because the function does not verify that the caller has any relationship to the NFT being deposited, allowing anyone to register as the depositor once the NFT is in the vault's possession.
This function has two critical issues:
It's publicly callable by anyone, not restricted to the EggHuntGame contract.
It allows the caller to specify any address as the depositor.
The deposit flow requires users to first transfer their NFT to the vault and then call depositEgg as separate transactions. This two-step process creates a time window for an attack:
User transfers their NFT (tokenId) to the vault
Before the user can call depositEgg, an attacker observes the transfer in the mempool
Attacker front-runs the user's depositEgg transaction with their own, specifying themselves as the depositor
The attacker's transaction succeeds because the NFT is already in the vault's possession
The user's subsequent depositEgg call fails with "Egg already deposited"
The attacker is now recorded as the legitimate depositor and can likely withdraw the NFT later
The function only checks that:
The NFT is currently owned by the vault
The NFT hasn't already been registered in storage
It fails to verify that the caller has any legitimate claim to the NFT that was transferred.
The impact of this vulnerability is severe:
Users can permanently lose their NFTs to attackers
Any value associated with the NFTs (which may be significant for rare or valuable NFTs) is stolen
The trust in the EggVault system is completely undermined
This vulnerability affects all users who attempt to deposit NFTs into the vault. The attack requires minimal technical expertise and resources to execute, making it highly exploitable in a production environment. Since NFTs can hold significant value, financial losses could be substantial.
Foundry
the EggHuntGame contract already implements a proper deposit flow with the depositEggToVault function, the direct access to depositEgg should be restricted.
The recommended approach is to:
Modify the depositEgg function in EggVault to only allow calls from the EggHuntGame contract:
Front-running depositEgg allows deposit ownership hijacking.
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.