Approval issues detection

When this applies

• Any approve / safeApprove / forceApprove site
• permit (EIP-2612, DAI-style, Permit2)
• Routers / aggregators that hold persistent approvals
• Vaults that approve strategies to pull funds
• Bridges / cross-chain approvers

Detection patterns

The classic ERC-20 approve race (HIGH)

token.approve(spender, X);   // later
token.approve(spender, Y);   // ← spender can front-run and drain X+Y

Use forceApprove(spender, Y) (OZ ≥4.9), or decreaseAllowance / increaseAllowance, or zero-first.

approve instead of safeApprove on non-standard tokens (HIGH)

USDT requires approve-to-zero before approve-to-X. Use OZ forceApprove.

Infinite approval to mutable contract (HIGH)

token.approve(router, type(uint256).max);   // ← router is upgradeable, future impl can drain

Mitigate with allowance-per-action.

Per-pull infinite approval (HIGH)

Vault → strategy infinite approval; if strategy is upgradeable or has a bug, vault funds drainable.

Permit2 sig stolen / replayed (HIGH)

Permit2 signatures are bearer instruments — anyone with the sig can transfer. If the signed payload is logged or leaked, funds are drainable until the nonce is invalidated. Add a deadline.

permit then ignore failure (MEDIUM)

try IERC20Permit(token).permit(owner, spender, ...) {} catch {}
token.transferFrom(owner, ...);   // ← if permit fails, uses any stale allowance

Caller can grief by front-running permit. Acceptable IFF you then check the allowance is sufficient.

Approval to address(0) on revoke (LOW)

Some tokens treat approve(0, x) as a no-op or revert. Use the documented revoke method.

Allowance still set after action completes (HIGH for routers)

token.safeApprove(target, amount);
target.swap(...);
// ← allowance lingers; if `amount` was max, target keeps power

Set to 0 after each action, or use a single-tx wrapper.

Approve to factory / clone-deployer (HIGH)

Deployer can deploy attacker-controlled implementation that consumes the approval.

Severity rubric

Remediation patterns

• Always use OZ forceApprove for setting; safeIncreaseAllowance for top-ups.
• After a router/exec call: safeApprove(target, 0) to reset.
• For vault→strategy: pull-only allowances and per-cycle resets.
• Permit2: short deadlines (minutes), per-payload nonce, bind to specific recipient + amount.
• For EOA users: surface the actual amount in the UI; never auto-approve max from the contract.

False-positive notes

• Internal-only approve where source and spender are both controlled → Info.
• WETH9-style approve returning bool always-true is well-known and safe.

Related

• [[token-compatibility]]
• [[signature-replay]] — Permit2 / EIP-2612
• [[mev-frontrunning]] — approve race is an MEV pattern