SwapNet Exploit Analysis

On January 25, 2026, the SwapNet DEX aggregator was exploited, resulting in a loss of approximately $13.4M across multiple chains (Base, BSC, Arbitrum).

SwapNet is a DEX aggregator designed to find optimal swap routes by aggregating liquidity from multiple on-chain sources, including AMMs and private market makers. The protocol allows users to specify custom routers or pools when executing swaps. Its smart contracts were closed-source and not verified on block explorers.

SwapNet Router

The SwapNet Router contract is the core contract that executes token swaps. Users approve their tokens to the router, and the router executes swaps through various DEX protocols (Uniswap V2/V3, Curve, etc.). The router supports multi-hop swap routing with user-supplied parameters.

The normal swap flow works as follows:

1. Users approve their tokens to the SwapNet Router contract

2. Users call a swap function with parameters specifying the input token, output token, and routing path

3. The router transfers the input tokens from the user, executes the swap through the specified DEXs, and sends the output tokens back to the user

Key Information

• SwapNet Router: https://basescan.org/address/0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e

• Upgrade Tx: https://basescan.org/tx/0xdf81a643b03c4364dd2740d3ac177d0184c5b4e432257aaa0c277d4eef88a011

• Attack Tx: https://basescan.org/tx/0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57

Exploit Analysis

The root cause of the exploit is an arbitrary-call vulnerability stemming from insufficient validation of user-supplied inputs in the SwapNet Router’s closed-source smart contracts.

Based on the decompiled bytecode, the vulnerable function 0x87395540() handles the core swap routing logic. For each swap step, the contract determines the DEX type and executes the appropriate swap. The contract supports dozens of DEX types identified by numeric codes in msg.data:

For certain DEX types (particularly the custom router type), the contract performs a low-level call to a user-supplied address (v75) with user-controlled calldata:

The critical issue is that no validation is performed on v75 (the call target address). The attacker exploited this by:

1. Setting the internal key variable v75 to the USDC token address instead of a legitimate DEX router, bypassing the intended routing logic.

2. Crafting the calldata to encode transferFrom(SwapNetRouter, attacker, amount).

3. Since the SwapNet Router contract held user approvals (from users who granted infinite approvals), the USDC.transferFrom() call succeeded, and the attacker drained all approved USDC.

The attack involved two main steps:

1. A key internal variable (e.g., v51) was set to USDC, bypassing intended routing logic.

2. A low-level call was executed using attacker-controlled calldata, resulting in USDC.transferFrom() being invoked, draining all approved USDC from users.

After the initial exploit on Base, the attacker swapped approximately $10.5M in USDC for ~3,655 ETH, then bridged the stolen funds to the Ethereum mainnet to obscure the transaction trail. The attacker continued to drain 17 additional users across 3 chains before SwapNet paused contracts ~45 minutes later.

Conclusion

The SwapNet exploit demonstrates the dangers of closed-source smart contracts and arbitrary-call vulnerabilities in DeFi protocols:

1. Insufficient Input Validation: The function lacked proper validation on the call target address. By replacing the expected router/pool address with a token address (e.g., USDC), the attacker tricked the contract into executing transferFrom() with attacker-controlled parameters.

2. Closed-Source Risk: Because SwapNet’s contracts were not verified on block explorers, the community could not review the code for vulnerabilities. The arbitrary-call flaw might have been caught through standard code review or audit.

3. Persistent Approval Danger: Users who granted infinite approvals directly to the SwapNet Router were exposed to maximum risk. The exploit drained the full approved balance, not just the amount from a single swap.

4. Missing Call Target Whitelist: The contract should have maintained a whitelist of valid DEX router addresses and rejected calls to any other address, especially token contract addresses.

This attack highlights the importance of open-source smart contracts, proper input validation on low-level calls, and the use of per-transaction approval patterns instead of persistent infinite approvals. The $13.4M loss could have been prevented through call target whitelisting, function selector validation, and open-source code review.