A critical race condition vulnerability exists in the _cancelFlow function due to improper handling of the global counter variable. This allows cancellation operations to reference incorrect deposit records when multiple users interact with the contract concurrently, leading to misdirected fund transfers and permanent loss of user assets.
The cancellation logic uses the current counter value to identify deposits:
counter variable increments on new deposits regardless of cancellation state, creating temporal coupling between unrelated operations.Initial State
User A deposits: counter = 5
depositInfo[5] contains A's 10 ETH
Cancellation Initiation
Admin begins cancelling A's deposit (still processing)
Race Condition Trigger
User B deposits: counter increments to 6
depositInfo[6] contains B's 20 ETH
Result:
User B receives refund of THEIR 20 ETH (depositId=6)
User A's 10 ETH remains locked (depositId=5 never processed)
User B gains double funds (original 20 ETH + cancellation refund)
Protocol loses 20 ETH
Fund loss
manual review
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
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.