Arbitrary from in transferFrom used with permit

Severity: High ID: arbitrary-send-erc20-permit

Flags transferFrom / safeTransferFrom calls whose from argument is not provably msg.sender (or address(this)) when the function also calls token.permit(owner, address(this), …) for the same token and owner beforehand.

What it does

Detects, within a single function, the combination of:

1. A preceding permit(owner, spender, value, deadline, v, r, s) on token with spender == address(this), and
2. A subsequent ERC20-style transfer of the same token from the same owner, where owner cannot be proven equal to msg.sender or address(this).

Both common sink shapes are recognised:

• Member calls: token.transferFrom(owner, to, amount) and token.safeTransferFrom(owner, to, amount).
• Library calls: Lib.safeTransferFrom(token, owner, to, amount), including the Solady-shaped using SafeTransferLib for address form.

The lint does not require the transfer amount to equal the permit value, nor does it inspect deadlines or signatures — the dangerous combination is the permit-then-arbitrary-transferFrom pattern itself, not the specific amounts.

Matching EIP-3156 flash-loan repayments (onFlashLoan followed by a pull-back of amount + fee) are excluded.

Scope

The check is intraprocedural. It flags one permit-then-transferFrom flow inside a single function body and correlates the token, owner, and spender by the underlying variable, with the following normalisations applied to both sides of the correlation:

• elementary type casts (address(x)), interface / contract casts (IERC20(rawToken)), payable(...) wraps, and parentheses are stripped;
• local var-to-var copies (IERC20 t = token; ..., address from2 = from; ...) are tracked as aliases, so the permit and the sink still correlate when one side is a copy;
• local aliases of address(this) (e.g. address self = address(this); permit(..., self, ...)) and no-arg helpers whose body is return address(this); are recognised as the permit spender;
• the using SafeTransferLib for address member form is treated as a sink.

Dead code after a top-level return / revert is skipped — including function bodies whose modifier prefix definitely exits before _;. Inline // forge-lint: disable-next-line(arbitrary-send-erc20-permit) suppresses a single sink.

Additionally supported correlations:

• struct-field token receivers (cfg.token.permit(...) then cfg.token.transferFrom(...)) match via a (base var, field name) key;
• the library wrapper SafeERC20.safePermit(token, ...) is treated as an EIP-2612 permit on the token argument when the receiver is a library;
• immutable / constant state vars proven equal to address(this) or msg.sender by their declaration initializer or constructor body are recognised as such at the start of every function;
• internal calls to functions of the same contract drop facts about every state variable the callee (or one nested level of internal callees) assigns to, so a prior permit is no longer trusted after the receiver may have been swapped.

Patterns the check still does not classify as the permit-variant (the underlying call may still be reported by arbitrary-send-erc20 when the sink itself is unguarded) include permits issued inside a called helper / modifier / parent contract.

Permits inside for / while loop bodies do not establish facts visible after the loop (the analyzer treats their execution count as possibly zero), so a transferFrom placed after the loop is not classified as the permit variant. A transferFrom inside the same iteration as the permit is still flagged.

Why is this bad?

A permit followed by transferFrom is the textbook EIP-2612 flow, so it looks safe. It is not safe when the token does not actually implement permit but has a fallback function (the canonical example is WETH). On such tokens:

• permit(...) is forwarded to the fallback and silently succeeds without authorizing anything.
• Any pre-existing allowance from another user to this contract can then be drained by anyone, because the contract trusts the (no-op) permit and forwards the attacker-supplied from straight into transferFrom.

The recommendation is to pin the supported token(s) at deploy time and verify they implement permit correctly, or to require from == msg.sender so that, even if the permit silently no-ops, only the caller's own balance is at risk.

If your code separately proves that permit succeeded (for example by reading token.nonces(owner) before and after and reverting on no change) or restricts the sink to a vetted token allowlist, review the finding and suppress with // forge-lint: disable-next-line(arbitrary-send-erc20-permit).

Example

Bad

function pullWithPermit(
    address from,
    address to,
    uint256 value,
    uint256 deadline,
    uint8 v,
    bytes32 r,
    bytes32 s
) external {
    token.permit(from, address(this), value, deadline, v, r, s);
    token.transferFrom(from, to, value); // arbitrary-send-erc20-permit
}

Good

function pullWithPermit(
    uint256 value,
    uint256 deadline,
    uint8 v,
    bytes32 r,
    bytes32 s
) external {
    // `from` is implicitly the caller — permit + transferFrom only touch the
    // caller's own balance, even if `token` is a non-permit token with a fallback.
    token.permit(msg.sender, address(this), value, deadline, v, r, s);
    token.transferFrom(msg.sender, address(this), value);
}