approval-issues

# 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) ```solidity 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) ```solidity 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) ```solidity try IERC20Permit(token).permit(owner, spender, ...) {} catch {} token.transferFrom(owner, ...); // ← if permit fails, uses any stale allowance ``` Caller ca...