# SocketGateway: unvalidated calldata in route drains $3.3M

SocketGateway route 406 lacked calldata validation, letting an attacker pass arbitrary transferFrom calldata to drain ~$3.3M USDC from users who approved the gateway.

- Payout: Real-world hack
- Severity: critical
- Program: SocketGateway
- Analysis by: DeFiHackLabs
- Disclosed: 2024-01-12
- Write-up quality: 7/10
- Original: https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2024-01/SocketGateway_exp.sol
- Library page: https://bugbountylibrary.com/r/dhl%3A20240112-socketgateway
- Tags: area:web3 domain:web3 impact:funds-loss kind:incident platform:defihacklabs sev:critical tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** SocketGateway executeRoute / performAction route
**Root cause:** The vulnerable route's performAction passed user-supplied swapExtraData directly as calldata to an external call without validating the target or selector, allowing arbitrary token transferFrom.
**Steps:**
1. Identify routeId 406 as a recently added vulnerable route on SocketGateway `0x3a23F943181408EAC424116Af7b7790c94Cb97a5`.
2. Build routeData calling `performAction(token, token, 0, attacker, bytes32(0), swapExtraData)` where swapExtraData is `transferFrom(victim, attacker, balance)`.
3. Call `gateway.executeRoute(406, routeData)`.
4. Route executes the arbitrary transferFrom using the victim's prior approval to the gateway, moving USDC to the attacker.
**How found:** Likely spotted the newly added route 406 and noticed performAction forwarded swapExtraData as raw calldata without validating selector or target, enabling arbitrary calls via existing approvals.
**Exploitation:** Attacker called executeRoute with routeId 406 and crafted routeData whose swapExtraData encoded IERC20.transferFrom(victim, attacker, victimBalance). The route forwarded this calldata to USDC, pulling funds from users who had approved the SocketGateway. Repeated across multiple victims to accumulate ~$3.3M.
**Escalation:** Batch multiple transferFrom calls across many approved users to scale the theft.
**Insight:** When a router exposes a generic performAction/swapExtraData parameter, check whether the calldata is forwarded unchecked; any user approval to the router becomes drainable via arbitrary transferFrom.