Unibot Approval Drain

2. Key Background

SocketGateway is a routing contract that dispatches user requests to route implementation contracts. The verified SocketGateway source shows two relevant execution surfaces: getRoute(uint32) returns the route implementation for a route id, and the fallback handler treats the first four calldata bytes as a route id, then delegatecalls into the mapped route. At the exploit block, the selected route id was 406, encoded on-chain as the first four bytes 0x00000196.

function getRoute(uint32 routeId) public view returns (address) {
    return addressAt(routeId);
}

fallback() external payable {
    address routeAddress = addressAt(uint32(msg.sig));
    result := delegatecall(gas(), routeAddress, 0, sub(calldatasize(), 4), 0, 0)
}

USDC at 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 uses the standard spender-based allowance model. The trace shows the attacker repeatedly queried balanceOf(victim) and allowance(victim, SocketGateway) before each drain attempt. This matters because if SocketGateway is the runtime caller of USDC.transferFrom, any pre-existing allowance[victim][SocketGateway] authorizes the spend.

The attack required no privileged roles, no private keys, and no protocol-admin transaction. The only prerequisite was a victim account with positive USDC balance and a positive USDC allowance to SocketGateway, a condition created by normal prior use of Socket routes.

3. Vulnerability Analysis & Root Cause Summary

The vulnerability is an application-layer arbitrary external call under a shared spender identity. WrappedTokenSwapperImpl was meant to wrap tokens into native ETH or vice versa, but its ERC20-to-native path does not validate that swapExtraData actually represents a legitimate wrapper action. Instead, it forwards arbitrary attacker-controlled calldata directly to the token contract.

The critical code is the ERC20 branch of WrappedTokenSwapperImpl::performAction:

_initialBalanceTokenOut = address(socketGateway).balance;

ERC20(fromToken).safeTransferFrom(
    msg.sender,
    socketGateway,
    amount
);

(bool success, ) = fromToken.call(swapExtraData);

if (!success) {
    revert SwapFailed();
}

_finalBalanceTokenOut = address(socketGateway).balance;

require(
    (_finalBalanceTokenOut - _initialBalanceTokenOut) == amount,
    "Invalid wrapper contract"
);

This creates a precise invariant violation: a route that is supposed to perform wrapping may instead invoke any token selector under SocketGateway authority. The exploit sets amount = 0, which makes the initial safeTransferFrom(msg.sender, socketGateway, amount) a harmless zero-value transfer from the attack helper. That bypasses the intended funding step while still reaching fromToken.call(swapExtraData). The attacker then encodes swapExtraData as USDC.transferFrom(victim, attacker, drainAmount), so the raw token call consumes the victim's pre-existing allowance to SocketGateway. The final ETH-balance check also passes trivially because both the expected and actual ETH delta are zero.

4. Detailed Root Cause Analysis

The exploit flow is deterministic and directly visible in the collected trace and balance diff. The transaction sender 0x50df5a2217588772471b84adbbe4194a2ed39066 created helper contracts 0xf2d5951bb0a4d14bdcc37b66f919f9a1009c05d1 and 0xd2bc9a9c2c39b8693ed4b2b72469032e87ed7f4a, then immediately entered the draining loop. For each victim, the helper first queried the victim's USDC balance and its allowance to SocketGateway.

One representative trace segment for victim 0x7d03149A2843E4200f07e858d6c0216806Ca4242 shows the full abuse path:

FiatTokenV2_2::allowance(0x7d03149A..., SocketGateway) -> 115792089237316195423570985008687907853269984665640564039457584007913029639935
SocketGateway::fallback(0x00000196...)
WrappedTokenSwapperImpl::performAction(
  fromToken = USDC,
  toToken = NATIVE,
  amount = 0,
  receiver = 0x856da0aCbfF24Fd61A470023E8A5dAE8FC45bde8,
  metadata = 0x...1b3b,
  swapExtraData = 0x23b872dd...
)
FiatTokenV2_2::transferFrom(0xd2bc9A9c..., SocketGateway, 0)
FiatTokenV2_2::transferFrom(0x7d03149A..., 0x50DF5a22..., 656424984436)

The key observations are:

1. The route selector 0x00000196 reaches SocketGateway fallback, confirming route 406 usage.
2. performAction is called with amount = 0, so the helper-to-gateway transfer is a no-op.
3. The malicious swapExtraData begins with selector 0x23b872dd, the ERC20 transferFrom(address,address,uint256) selector.
4. The second FiatTokenV2_2::transferFrom drains the real victim address into the attacker EOA.

This pattern repeats across 127 victim addresses. The seed balance diff aggregates the outcome: the attacker EOA starts at zero USDC and ends with 2569980189709, while the negative USDC deltas across victims sum to the exact same value. The attack therefore did not rely on hidden value sources or privileged settlement. It is a straight conversion of third-party allowance[victim][SocketGateway] into attacker-controlled transfers.

The exploitable preconditions are also explicit:

1. route 406 must still map to WrappedTokenSwapperImpl;
2. the target victim must have positive USDC balance;
3. the target victim must have positive USDC allowance to SocketGateway;
4. the attacker must choose drainAmount <= min(balanceOf(victim), allowance(victim, SocketGateway)).

Under those conditions, the exploit succeeds for any unprivileged actor able to submit a normal transaction.

5. Adversary Flow Analysis

The adversary strategy was a single-transaction allowance sweep. The EOA 0x50df5a2217588772471b84adbbe4194a2ed39066 paid gas and received the stolen funds. The two helper contracts existed only to package the victim list and loop over repeated drain attempts.

The end-to-end execution flow was:

1. Deploy an outer helper contract from the attacker EOA.
2. Deploy an inner helper contract from the outer helper.
3. For each victim address in the embedded list:
   • read USDC.balanceOf(victim);
   • read USDC.allowance(victim, SocketGateway);
   • compute a drain amount bounded by both values;
   • call SocketGateway fallback with route id 406, amount = 0, and swapExtraData = abi.encodeWithSelector(transferFrom, victim, attacker, drainAmount).
4. Receive all drained USDC directly in the attacker EOA.

The trace shows that the inner helper repeatedly executed SocketGateway::fallback(0x00000196...) frames followed by nested FiatTokenV2_2::transferFrom(victim, attacker, amount) calls. No victim signatures, approvals, or per-victim interactions occurred inside the exploit transaction itself. All spend authority was inherited from approvals that already existed before block 19021454.

6. Impact & Losses

The measurable impact is a direct theft of USDC from 127 accounts that had approved SocketGateway. The seed transaction balance diff records the attacker's final gain and the victims' aggregate loss as the same raw value:

{
  "attacker": "0x50df5a2217588772471b84adbbe4194a2ed39066",
  "token": "USDC",
  "before": "0",
  "after": "2569980189709",
  "delta": "2569980189709"
}

Expressed with USDC's 6 decimals, the loss is 2569980.189709 USDC. Gas cost was borne separately by the attacker EOA in ETH and does not offset the victims' token loss. The scope of impact is any user address that both held USDC and had granted SocketGateway a usable allowance during the vulnerable route configuration.

7. References

1. Seed transaction 0xc6c3331fa8c2d30e1ef208424c08c039a89e510df2fb6ae31e5aa40722e28fd6 metadata and trace.
2. Seed transaction balance diff showing the attacker's USDC gain and the matching aggregate victim losses.
3. Verified SocketGateway source for fallback route dispatch and getRoute.
4. Verified WrappedTokenSwapperImpl source for the unvalidated fromToken.call(swapExtraData) path.
5. Collected USDC FiatTokenV2_2 source artifact showing spender-based allowance behavior.