# Deployer wallet retains ability to spoof validated senders after ownership transfer

Deployer EOA can redeploy a spoofed InterchainTokenService at the same CREATE3 address on a new chain and pass validateSender, enabling arbitrary token transfers.

- Payout: Contest reward
- Severity: medium
- Program: Axelar Network
- Credited: pcarranzav
- Disclosed: 2023-11-29
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-07-axelar-findings/issues/267
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-axelar%3AM-06
- Tags: domain:web3 impact:funds-loss impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:chained technique:source-review vuln:access-control vuln:auth-bypass vuln:privilege-escalation

**Target:** RemoteAddressValidator / InterchainTokenService (Solidity, CREATE3 deployment)
**Root cause:** validateSender treats any source address equal to the immutable interchainTokenServiceAddress as trusted regardless of source chain, and that address is deterministically reproducible by the original deployer EOA via CREATE3 on any new chain.
**Steps:**
1. Deployer deploys all contracts on chain A; ownership of RemoteAddressValidator transferred to governance multisig.
2. Deployer (or compromised key) deploys Create3Deployer at same address on new chain B and replays deployment with same salt to get InterchainTokenService at identical address.
3. Replace ITS implementation with one exposing `callContract(destinationChain, payload, gasValue, refundTo) external onlyOwner` that calls `_callContract`.
4. Send payload with `SELECTOR_SEND_TOKEN` and destination = deployer address to ITS on chain A.
5. On chain A, `validateSender` sees `sourceAddressHash == interchainTokenServiceAddressHash` and returns true, so tokens are transferred to deployer.
**How found:** Code reading of validateSender's special-case hash comparison combined with the CREATE3 deployment script showing the ITS address is deterministic from deployer address, Create3Deployer address and salt; reasoned that a new chain lets the deployer reproduce the address with arbitrary code.
**Exploitation:** Requires deployer EOA compromise (or malicious insider) plus a new EVM chain added to Axelar. Attacker redeploys a malicious ITS at the canonical CREATE3 address on the new chain, then sends a crafted sendToken message that chain A's RemoteAddressValidator accepts as originating from the trusted ITS, draining/transferring tokens to the attacker.
**Escalation:** Privilege persists after ownership transfer to multisig; compromise of a single EOA yields protocol-wide token transfer authority on all chains trusting the canonical ITS address.
**Insight:** When a contract address is treated as an implicit trust anchor, check whether that address is deterministically reproducible by a lower-privileged party (CREATE2/CREATE3, same deployer+salt) on chains not yet deployed; special-case address equality checks should also bind the source chain.