# UnionToken should check whitelist on from?

UnionToken's _beforeTokenTransfer whitelist check uses msg.sender instead of from, letting one whitelisted operator move any account's tokens and bypass the whitelist.

- Payout: Audit contest
- Severity: medium
- Program: Union Finance
- Found by: cmichel
- Disclosed: 2021-12-08
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-10-union-findings/issues/69
- Library page: https://bugbountylibrary.com/r/c4%3A2021-10-union%3AM-03
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:access-control vuln:business-logic

**Target:** ERC20 token transfer hook (_beforeTokenTransfer)
**Root cause:** The whitelist gate in _beforeTokenTransfer validates msg.sender rather than the token owner `from`, so any whitelisted caller (e.g. an approved operator/relayer) can transfer tokens out of non-whitelisted accounts.
**Steps:**
1. Non-whitelisted holder calls `unionToken.allow(operator, max)` granting a whitelisted contract/operator allowance.
2. Whitelisted operator calls `unionToken.transferFrom(victim, recipient, amount)`.
3. _beforeTokenTransfer runs with msg.sender = whitelisted operator, passes `isWhitelisted(msg.sender)` check.
4. Transfer succeeds despite `from` (victim) not being whitelisted, bypassing the guest list.
**How found:** Code reading of the _beforeTokenTransfer hook: noticed the require checks msg.sender instead of from, and reasoned that msg.sender can be a relayer/operator distinct from the token owner.
**Exploitation:** A single whitelisted account acting as operator for many holders can move tokens from non-whitelisted accounts, effectively nullifying the whitelist restriction on transfers.
**Insight:** In ERC20 hooks, msg.sender is the caller (operator/relayer), not the token owner; access-control gates meant to restrict holders must key on `from`/`to`, not msg.sender.