# MulticallWithXera: msg.sender spoofing drains token approvals

Multicall's aggregate3 let attacker spoof victim as msg.sender to Xera token, draining approved tokens and swapping for 41 WBNB (~$17k).

- Payout: Real-world hack
- Severity: high
- Program: MulticallWithXera
- Credited: DeFiHackLabs
- Disclosed: 2025-08-20
- Write-up quality: 6/10
- Original: https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2025-08/MulticallWithXera_exp.sol
- Library page: https://bugbountylibrary.com/r/dhl%3A20250820-multicallwithxera
- Tags: domain:web3 impact:funds-loss kind:incident platform:defihacklabs sev:high tech:evm technique:source-review vuln:access-control vuln:business-logic

**Target:** Multicall contract aggregate3 and Xera token transferFrom
**Root cause:** Xera token's _msgSender() incorrectly returns the original caller (victim) instead of the immediate caller (Multicall) when invoked via Multicall's aggregate3, allowing transferFrom to succeed using victim's approval to Multicall.
**Steps:**
1. Victim approved Multicall contract to spend Xera tokens.
2. Attacker calls `aggregate3` on Multicall with a Call3 targeting Xera token, callData `transferFrom(victim, cakeLP, 27900000000000000000000000)`.
3. Xera's `_msgSender()` returns victim as msg.sender, so `transferFrom` moves victim's tokens to cakeLP.
4. Attacker calls `swap(0, 41034748173552867045, attacker, "")` on cakeLP to convert stolen Xera to WBNB.
5. Attacker calls `withdraw` on WBNB to unwrap to BNB.
**Exploitation:** Attacker used Multicall's aggregate3 to invoke Xera token's transferFrom with victim as from, exploiting _msgSender() misimplementation to bypass allowance check, then swapped stolen tokens for WBNB and unwrapped.
**Insight:** When a token overrides _msgSender() to return tx.origin or original caller, any multicall or meta-transaction forwarder can be abused to impersonate approvers; check token contracts for non-standard _msgSender() implementations.