Multichain (Anyswap) `anySwapOutUnderlyingWithPermit` — Missing-`permit` Allowance Theft

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2022-11-NUM_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/NUM_exp.sol.

Vulnerability classes: vuln/dependency/unchecked-return-value · vuln/logic/missing-validation

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. Full verbose trace: output.txt. Verified vulnerable source: AnyswapV4Router.sol. This PoC reproduces one victim (the NUM token holder) of the November-2022 Multichain/Anyswap router incident; the same router bug affected many WETH/ PERI/etc. approvers across chains for a combined ~$3M+.

Key info#

TL;DR#

Multichain's AnyswapV4Router.anySwapOutUnderlyingWithPermit() is supposed to let a user authorize a cross-chain transfer with a single EIP-2612 signature: the router calls underlying.permit(from, router, amount, …, v, r, s) to set the allowance, then transferFrom(from, anyToken, amount) (AnyswapV4Router.sol:257-273).

The fatal assumption is that permit() actually verifies the signature. For tokens whose "underlying" is an Anyswap proxy that has no permit function (like NUM's ERC677InitializableToken), the call lands on the token's empty fallback, does nothing, and succeeds. The router never checks that permit consumed the signature — so a forged, all-zero signature "passes."

Worse, from and token are fully attacker-controlled parameters. Many users had already granted the router an infinite allowance on these tokens (the normal way to use the bridge). So the attacker:

1. Passes token = <their own contract> (which returns NUM as its underlying() and stubs depositVault/burn), and from = victim who has an existing approve(router, ∞) on NUM.
2. The router calls NUM.permit(victim, router, 557k, …, 0, 0x3078…, 0x3078…) → no-op success.
3. The router then does NUM.transferFrom(victim → attackerContract, 557,754.45 NUM), draining the victim's NUM into the attacker contract using the victim's pre-existing allowance.
4. The attacker dumps the stolen 557,754.45 NUM into the NUM/USDC pool for 13,822.28 USDC.

The "permit" step is pure theater; the actual theft rides on the victim's standing allowance plus the router's willingness to transferFrom arbitrary from/token pairs.

Background — the Anyswap router model#

AnyswapV4Router (source) bridges an "anyToken" (a wrapper with mint/burn/underlying/depositVault) and its underlying ERC-20. To start a bridge-out the user normally:

• approves the router on the underlying, then
• calls anySwapOutUnderlying(token, to, amount, toChainID), which pulls the underlying via transferFrom(msg.sender → anyToken) (:251-255).

The …WithPermit variants (:257-273) were added so a user without an existing allowance could authorize the pull in the same transaction by supplying an EIP-2612 signature — the router would call permit() to set the allowance, then transferFrom.

The on-chain facts at fork block 16,029,969:

The infinite allowance is the precondition that turns a stuck signature check into a draining primitive: the router does not need permit to grant a new allowance — the victim already gave the router one.

The vulnerable code#

1. permit() is called but its result is never validated#

function anySwapOutUnderlyingWithPermit(
    address from,                       // ⚠️ attacker-supplied victim address
    address token,                      // ⚠️ attacker-supplied (their own contract)
    address to,
    uint amount,                        // ⚠️ attacker-supplied (= victim's full balance)
    uint deadline,
    uint8 v, bytes32 r, bytes32 s,      // ⚠️ forged: v=0, r=s=0x3078…
    uint toChainID
) external {
    address _underlying = AnyswapV1ERC20(token).underlying();          // → NUM
    IERC20(_underlying).permit(from, address(this), amount, deadline, v, r, s);  // ⚠️ no-op on NUM
    TransferHelper.safeTransferFrom(_underlying, from, token, amount); // ⚠️ pulls via standing allowance
    AnyswapV1ERC20(token).depositVault(amount, from);                  // stubbed by attacker
    _anySwapOut(from, token, to, amount, toChainID);                   // burn() stubbed by attacker
}

AnyswapV4Router.sol:257-273

TransferHelper.safeTransferFrom only checks that the low-level call succeeded and (optionally) returned true (:132-136) — it has no concept of whether a meaningful permit ran first.

2. NUM's token has no permit, so the call silently succeeds#

NUM is a TokenProxy (contracts_TokenProxy.sol) that delegatecalls every selector to its implementation (zos-lib_contracts_upgradeability_Proxy.sol:30-49). The implementation (ERC677InitializableToken) does not implement permit(address,address,uint256,uint256,uint8,bytes32,bytes32).

In Solidity, calling a non-existent function with a bytes-style fallback present (the proxy's function () payable external) routes to that fallback, which here delegatecalls into the impl's own (empty) fallback — it neither reverts nor verifies anything. In the trace this is the ERC677InitializableToken::fallback(…) [delegatecall] ← [Stop] at output.txt L1590-1593. The forged signature is never inspected.

Root cause — why it was possible#

Four design decisions compose into the bug:

1. Trusting an unverified external permit. The router treats permit() as if it atomically sets an allowance from a verified signature. For any underlying without EIP-2612 (or with a permissive fallback / non-reverting stub), the call is a no-op and the router proceeds anyway. The router never asserts allowance(from, router) >= amount was created by this permit.
2. Fully attacker-controlled from and token. Nothing ties from to msg.sender. The attacker names any victim as from and supplies their own contract as token, whose underlying() points at the real NUM and whose depositVault/burn are no-op stubs. This lets the attacker choose both the victim and the destination of the pulled funds.
3. Pre-existing infinite allowances. Because the normal bridge flow asks users to approve(router, ∞), the router already had spending power over victims' tokens — so a working permit was never actually needed to move funds; the standing allowance sufficed.
4. safeTransferFrom recipient = token (attacker contract). The pulled underlying is sent to token, which is the attacker's contract — so the attacker directly receives the victim's tokens, then dumps them.

In short: permit was assumed to be a gate, but on these tokens it was an unlocked door, and the victims had already handed the router the keys (allowances).

Preconditions#

• A victim has a standing allowance to the router on the underlying token (true for NUM victim: pre-attack allowance slot reads 0xffff…).
• The underlying token lacks a reverting permit — NUM's ERC677InitializableToken has no permit, so the proxy fallback returns success.
• Attacker can deploy a contract exposing underlying() → NUM, plus stub depositVault/burn (the PoC's ContractTest does exactly this — test/NUM_exp.sol:60-70).
• The router pulls from's balance — capped only by min(balance, allowance). No capital required; the attack is pure value extraction from existing approvers.

Attack walkthrough (with on-chain numbers from the trace)#

All figures are taken directly from output.txt.

Pool math at the dump#

Before the dump the NUM/USDC pair held NUM=4,471,975.99 / USDC=124,980.34 (getReserves, L1657-1658). The attacker added 557,754.45 NUM (the stolen amount, sent to the pair via the router — note onTokenTransfer reverts harmlessly as the pair has no ERC677 hook, L1645-1647). With the 0.3% fee:

amountOut = (557,754.45·0.997 · 124,980.34) / (4,471,975.99 + 557,754.45·0.997)
          ≈ 13,822.28 USDC

matching the Swap(amount0In: 557,754.45e18, amount1Out: 13,822.28e6) event at L1666. Post-swap pool reserves: NUM 5,029,730.44 / USDC 111,158.06 (L1660-1661, L1673).

Profit accounting#

The victim, who lost 557,754.45 NUM (their entire balance) plus suffered the pool price impact, bears the loss. The router itself moved no value — it merely lent its transferFrom privilege to the attacker.

Diagrams#

Sequence of the attack#

Why the "permit" gate fails open#

Trust assumption broken#

Remediation#

1. Verify permit actually granted the allowance. After calling permit(), assert IERC20(_underlying).allowance(from, address(this)) >= amount and that this allowance was created by the permit (e.g., snapshot before/after, or require the nonce to have advanced). A no-op permit must not be allowed to pass.
2. Do not accept arbitrary token/from. Maintain an allowlist of supported anyTokens and their genuine underlyings, and bind from to msg.sender for permit flows. The attacker's ability to supply a self-implemented token whose underlying() it controls is central to the exploit.
3. Never rely on standing infinite allowances as an authorization substitute. The permit path exists precisely so users need not pre-approve; if a permit fails to set an allowance, the call must revert rather than fall through to a pre-existing approval.
4. Reject tokens without EIP-2612 from the …WithPermit entrypoints. If _underlying does not support a standards-compliant, reverting permit, the permit variants should not be callable for it (use a registry flag or a probe that requires permit to revert on a bad signature).
5. Users: revoke router allowances. The general mitigation broadcast at the time was to revoke approvals to the affected Multichain/Anyswap routers, since the standing allowance is the load-bearing precondition.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to whole-compile under forge test):

_shared/run_poc.sh 2022-11-NUM_exp --mt testExploit -vvvvv

• RPC: an Ethereum mainnet archive endpoint is required (fork block 16,029,969).
• Result: [PASS] testExploit() — attacker ends with 13,822.28 USDC pulled from the NUM victim with zero capital.

Expected tail:

Ran 1 test for test/NUM_exp.sol:ContractTest
[PASS] testExploit() (gas: 279176)
  [End] Attacker USDC balance after exploit: 13822.280101

Suite result: ok. 1 passed; 0 failed; 0 skipped

References: BlockSec analysis — https://twitter.com/BlockSecTeam/status/1595346020237352960 ; DeFiHackLabs (Multichain / Anyswap anySwapOutUnderlyingWithPermit, Nov 2022).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-11-NUM_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: NUM_exp.sol.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "Multichain (Anyswap) anySwapOutUnderlyingWithPermit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.