Skip to content
medium Token Standards SWC-114 CWE-362

ERC20 approve() Race Condition

SAFE-0109 Token Standards Checked automatically by the scanner
1

What goes wrong

approve() overwrites an existing non-zero allowance directly. A spender watching the mempool can spend the old allowance and then also spend the new one, transferring more than the owner intended.

2

The vulnerable pattern

proof of concept — how it is exploited
// owner has approved 100. Owner sends approve(50).
// spender front-runs: transferFrom(100). Then the approve(50) lands.
// spender transferFrom(50). Total spent = 150 > intended.
3

How to fix it

the pattern that is safe
// force allowance through zero, or use increase/decreaseAllowance
token.approve(spender, 0);
token.approve(spender, newAmount);
// or: token.safeIncreaseAllowance(spender, delta);
◆
Known ERC20 approve/transferFrom race.
4

Related vulnerabilities in Token Standards

SAFE-0053Unsafe / Unprotected Minting critical · Token Standards SAFE-0051Missing SafeERC20 / Non-Standard Token Handling high · Token Standards SAFE-0052Fee-on-Transfer / Rebasing Token Accounting Mismatch high · Token Standards SAFE-0055Burn Authorization / Burn-From Missing Checks high · Token Standards SAFE-0107Fee-on-Transfer / Rebasing Token Mis-Accounting high · Token Standards SAFE-0208Non-Standard ERC20 Return Value Not Handled high · Token Standards SAFE-0050ERC-20 Approval Race Condition medium · Token Standards SAFE-0054ERC-721/1155 Missing Receiver Validation (Safe Transfer) medium · Token Standards
← PreviousFee-on-Transfer / Rebasing Token Mis-Accounting
Check your own contract for this

The SaferICO scanner runs 201 detectors over your Solidity source, SAFE-0109 among them. Paste an address or the source itself — a small per-scan fee, shown before you sign, or unlimited on any plan.

Run the scanner See how it is attacked Read the docs