The contract attempts to prevent division by zero by setting totalAmountBefore = 1 when totalAmountBefore == 0. However, this results in incorrect share allocation, allowing a new depositor to receive an unfairly high number of shares, potentially claiming all existing shares for free.
In the code it calculates totalAmountBefore based on existing contract balance.
Checks if totalAmountBefore == 0
if ture, sets totalAmountBefore = 1 to prevent division by zero
EXPLOIT SCENARIO
totalShares = 1,000,000
totalAmountBefore = 0 (No active position or collateral)
A user notices that totalAmountBefore ==0 and prepares an exploit
Depositor A deposits 1 token.(assume minimum deposit, get to know that irrespective of the minimum deposit set this will still be exploited).
Contract sets totalAmountBefore = 1 to avoid division by zero
Shares calculation
Depositor A now owns 100% of the total shares
If another user deposits later they get minimal shares.
A single malicious users can seize all contract shares
A new deposit gets an unfairly large number of shares
An attacker can monitor for tpotalAmountBefore == 0 and steal all existing shares with a small deposit.
Manual Review
No proof when this can happen: Most of the time totalAmountBefore equals 0 (balance minus amount sent), it means totalShares equals 0. If it could happen with very specific conditions, report with that tag didn't add the needed details to be validated.
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.