The current implementation of the deposit
function allows users to deposit tokens before a specified deadline without any minimum amount restriction. This introduces a critical vulnerability where an attacker can exploit the system by front-running legitimate users. Specifically, just before the deadline, an attacker can:
Monitor pending transactions from genuine participants intending to deposit and participate.
Front-run those transactions by depositing a minimal amount, which can manipulate the outcome of the process (e.g., finalizing the list of participants or determining rewards) and after refund the money used in this attack leaves the participaton list small and the legimit persons who want to participate and come to dinner wont get the chance.
This issue is exacerbated by the absence of a minimum deposit threshold, allowing attackers to execute the exploit with negligible cost.
Observe that there is no limit set for amount in the deposit function and due which it is vulnerable to FrontRunning attack.
There is no validation to ensure _amount
exceeds a specific threshold. This allows deposits of any size, including negligible amounts, which can be exploited in front-running scenarios.
Front-run those transactions by depositing a minimal amount, which can manipulate the outcome of the process (e.g., finalizing the list of participants or determining rewards) and after refund the money used in this attack leaves the participaton list small and the legimit persons who want to participate and come to dinner wont get the chance.
Manual
Implement a Minimum Deposit Threshold
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.