# Dexible selfSwap arbitrary router call drains victim approvals

Dexible selfSwap accepted an arbitrary router address, letting an attacker call TRU.transferFrom on a victim's approved tokens and steal ~$1.5M.

- Payout: Real-world hack
- Severity: critical
- Program: - Dexible
- Analysis by: DeFiHackLabs
- Disclosed: 2023-02-17
- Write-up quality: 6/10
- Original: https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2023-02/Dexible_exp.sol
- Library page: https://bugbountylibrary.com/r/dhl%3A20230217-dexible
- Tags: area:web3 domain:web3 impact:funds-loss kind:incident platform:defihacklabs sev:critical tech:evm tech:solidity vuln:access-control vuln:business-logic

**Target:** Dexible selfSwap router contract
**Root cause:** selfSwap trusted the caller-supplied router address and executed arbitrary calldata against it, so any contract (e.g. a token) could be invoked with the victim's existing Dexible allowance.
**Steps:**
1. Attacker approves USDC to Dexible and calls `selfSwap` with `tokenIn` of 14,403,789 USDC.
2. Set `routes[0].router` to the TRU token address `0x4C19596f5aAfF459fA38B0f7eD92F11AE6543784` instead of a real router.
3. Set `routerData` to `transferFrom(victim, attacker, amount)` where amount is min(victim TRU balance, victim's TRU allowance to Dexible).
4. Dexible executes the calldata against the TRU token, pulling the victim's TRU to the attacker.
**Exploitation:** Attacker supplied a tiny USDC input and pointed the router at the TRU token contract, using the victim's pre-existing TRU allowance to Dexible to transferFrom the victim's full approved balance to the attacker.
**Insight:** When a swap/aggregator contract lets callers specify the router target, check whether any token with outstanding user allowances can be passed as the 'router' so its transferFrom runs with the user's approval.