Description
Initial Setup:
User A has registered with 100 tokens.
The registrations
mapping has an entry: registrations[User A] = 100
.
Assume the initial allowance is 0.
Unregister Call:
User A calls unregister()
.
Inside the unregister
function, the current allowance (allowance
) is retrieved, and then the function increments it by the registered amount (100 tokens).
Race Condition:
Suppose a malicious actor (or a bot controlled by User A) detects that unregister()
has been called. It quickly sends a transaction that uses up this allowance before the second approve call completes.
This allows the malicious actor to drain the tokens incrementally. If the contract does not reset the allowance to zero between calls, this action can be repeated, exploiting the incremented allowance.
Result:
By exploiting the race condition, User A (or an attacker) could withdraw more than 100 tokens by calling other transactions in between the approval increments.
Impact
. Unauthorized Token Transfers (Double-Spending)
.Loss of Contract Funds
Proof of Concepts
Recommended mitigation
This approach ensures that the allowance is safely reset before being reassigned, which makes the function resistant to race condition exploits.
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.