This is a lower bound: only assets with reliable historical USD prices are counted, so the actual loss may be higher.
0x4b4143cbe7f5475029cf23d6dcbb56856366d91794426f2e33819b9b1aac4e960x5a9fd7c39a6c488e715437d7b1f3c823d5596ed1EthereumAn unprivileged EOA exploited the LiFi diamond router on Ethereum mainnet by calling the public CBridgeFacet.swapAndStartBridgeTokensViaCBridge entry with attacker-crafted SwapData that caused the router to execute arbitrary ERC-20 transferFrom calls using long-standing user allowances. In a single transaction (0x4b41…4e96), tokens were drained from 20 unrelated holders across USDC, AudiusToken, GnosisToken, and SetToken and sent directly to an adversary EOA 0x8780…177e. The router exposed a public swap-and-bridge function that forwarded attacker-controlled SwapData into a generic LibSwap.swap primitive, which allowed arbitrary external calls (including ERC-20 transferFrom) to be executed under the router’s msg.sender with no check that the token owners matched the current caller or transaction receiver.
LiFi operates a diamond-proxy router on Ethereum (0x5a9f…6ed1) that aggregates swaps and bridges across multiple underlying protocols via modular facets (including CBridgeFacet). Users typically approve the router as an ERC-20 spender once and then rely on router functions to perform swaps/bridges on their behalf. The CBridgeFacet exposes swapAndStartBridgeTokensViaCBridge, which is intended to swap a user’s tokens into a bridge asset and then initiate a CBridge transfer. Internally it defers all swap logic to a shared LibSwap.swap helper that takes arbitrary SwapData describing which contracts to call, which tokens to move, and the calldata to use. ERC-20 allowances enable a contract such as the LiFi router to call transferFrom on a user’s behalf. A secure router must ensure that it only consumes allowances belonging to the user who initiated the current action or a closely related controlled account; using allowances of unrelated third parties violates basic expectations of token custody.
CBridgeFacet.swapAndStartBridgeTokensViaCBridge forwards attacker-supplied SwapData into LibSwap.swap, which permits arbitrary external calls (including ERC-20 transferFrom) to be executed by the LiFi router under its own msg.sender using any allowances previously granted to the router, without verifying that the from-addresses correspond to the current caller or intended receiver. This design lets an attacker sweep tokens from any holder that has approved the router.
The LiFi diamond router 0x5a9f…6ed1 is implemented as a standard EIP-2535-style diamond with a fallback that dispatches function selectors to facet addresses stored in LibDiamond.DiamondStorage. CBridgeFacet is one such facet and exposes swapAndStartBridgeTokensViaCBridge(ILiFi.LiFiData, LibSwap.SwapData[] memory _swapData, CBridgeFacet.CBridgeData memory _cBridgeData) as a public function reachable via selector 0x01c0a31a. This function is designed to (1) read the router’s current balance of the bridge token (or ETH), (2) execute a sequence of swaps via LibSwap.swap for each entry in _swapData, (3) compute _cBridgeData.amount as the post-swap increase in the router’s balance of the bridge token, and (4) call _startBridge to approve the bridge and invoke ICBridge.send/sendNative.
LibSwap.swap is a generic helper used across LiFi facets. For each SwapData entry it receives, it (a) ensures the router holds at least fromAmount of sendingAssetId, pulling additional tokens from msg.sender via LibAsset.transferFromERC20 if necessary, (b) sets an allowance for approveTo over the sendingAssetId, and then (c) performs a low-level call to callTo with arbitrary callData and value msg.value. Crucially, LibSwap imposes no restrictions on callTo or callData beyond type signatures; it does not require that callTo be a trusted DEX, nor does it decode callData to verify that the called function and its parameters conform to an expected swap.
In the exploit transaction, the attacker constructs SwapData entries that cause LibSwap.swap to skip any meaningful swap and instead call ERC-20 token contracts directly with transferFrom(from, to, amount) calldata, where from is set to a series of unrelated addresses that had previously approved 0x5a9f…6ed1 for USDC, AudiusToken, GnosisToken, or SetToken, and to is set to the adversary EOA 0x8780…177e. Because these transferFrom calls are executed by the LiFi router as msg.sender, they succeed as long as the victims’ allowances to the router are sufficient. There is no check in CBridgeFacet or LibSwap that the from-address matches the transaction sender 0xc6f2…d76 or the LiFiData.receiver, and no whitelist limits which token contracts or function selectors may be targeted.
The prestateTracer output and balance_diff.json demonstrate that, starting from σ_B with long-standing user allowances in place, executing swapAndStartBridgeTokensViaCBridge with the attacker-crafted SwapData deterministically results in net outflows from 20 victim holders and matching inflows to 0x8780…177e across the four tokens. The broken invariant is therefore directly attributable to LibSwap.swap’s ability to issue arbitrary external calls using the router’s allowances, combined with CBridgeFacet’s exposure of this primitive via a public, unprivileged entry point.
// LibSwap.swap (excerpt)
function swap(bytes32 transactionId, SwapData calldata _swapData) internal {
uint256 fromAmount = _swapData.fromAmount;
uint256 toAmount = LibAsset.getOwnBalance(_swapData.receivingAssetId);
address fromAssetId = _swapData.sendingAssetId;
if (!LibAsset.isNativeAsset(fromAssetId) && LibAsset.getOwnBalance(fromAssetId) < fromAmount) {
LibAsset.transferFromERC20(_swapData.sendingAssetId, msg.sender, address(this), fromAmount);
}
if (!LibAsset.isNativeAsset(fromAssetId)) {
LibAsset.approveERC20(IERC20(fromAssetId), _swapData.approveTo, fromAmount);
}
(bool success, bytes memory res) = _swapData.callTo.call{ value: msg.value }(_swapData.callData);
if (!success) {
string memory reason = LibUtil.getRevertMsg(res);
revert(reason);
}
}
Caption: LibSwap.swap executes a low-level call to attacker-chosen callTo with arbitrary callData using the diamond router as msg.sender, after optionally pulling tokens from msg.sender and granting allowances.
{
"token": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
"holder": "0x878099f08131a18fab6bb0b4cfc6b6dae54b177e",
"before": "0",
"after": "202012284580",
"delta": "202012284580"
}
Caption: Excerpt from balance_diff.json for tx 0x4b41…4e96 showing the profit EOA 0x8780…177e receiving 202,012.28458 USDC (202012284580 raw units) during the exploit transaction.
The adversary prepared an EOA pair, used prior user-granted allowances to the LiFi router as the value source, and executed a single unprivileged swapAndStartBridgeTokensViaCBridge call that swept tokens from many holders into a profit EOA; subsequent Uniswap V3 swaps and minor ETH transfers simply reshaped and paid for this stolen portfolio.
Stage: Adversary preparation and funding
Stage: Exploit transaction draining allowances
Stage: Post-exploit consolidation and swaps
The exploit drained tokens from 20 distinct holder addresses across four ERC-20 contracts: approximately 202,062.148578 USDC, 1202.371620631794480684 AUDIO, 0.944405031229340416 GNO, and 22.950860845096132852 DPI-equivalent SetToken. These losses are concentrated among individual users who had previously interacted with the LiFi router and granted it allowances. The LiFi router contract itself does not lose value but functions as the unwitting executor of the attacker’s arbitrary transferFrom calls, damaging user trust and requiring off-chain recovery efforts.
Token-level loss overview: