approve() Reverts on Non-Zero Allowance (USDT-style)

SAFE-0209 Token Standards Checked automatically by the scanner

What goes wrong

The code calls approve(spender, x) on tokens (like USDT) that revert when the current allowance is non-zero. Any second approval reverts, permanently blocking the integration for that token.

The vulnerable pattern

proof of concept — how it is exploited

// first approve(spender, 100) ok.
// later approve(spender, 200) on USDT -> reverts because allowance != 0
// -> the vault can never re-approve; deposits stuck.

How to fix it

the pattern that is safe

token.safeApprove(spender, 0);
token.safeApprove(spender, amount);
// or forceApprove / increaseAllowance

◆

Reset to zero first, or use forceApprove.

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

← PreviousNon-Standard ERC20 Return Value Not Handled Next →Tokens Transferable to the Contract Itself (Locked)

Check your own contract for this

The SaferICO scanner runs 201 detectors over your Solidity source, SAFE-0209 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