# Cross-chain replay attacks are possible with `changeRecipientAddress()`

Vault.changeRecipientAddress() signs data without chain.id, letting an attacker replay a wrong-network signature on the correct chain and steal funds.

- Payout: Contest reward
- Severity: medium
- Program: Harpie
- Credited: minhquanym
- Disclosed: 2022-09-16
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-09-harpie-judging/tree/main/004-M
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-09-harpie%3AM-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:signature-replay

**Target:** Solidity Vault contract signature validation
**Root cause:** The signed payload for changeRecipientAddress() omits chain.id, so a signature valid on one chain is valid on another at the same contract address.
**Steps:**
1. User calls `changeRecipientAddress()` on the wrong network, producing a signature over recipient data without chain.id
2. Attacker observes the signed payload
3. Attacker submits the same signature to the Vault on the intended chain (same contract address)
4. Attacker deploys/controls the recipient address the user specified and receives the funds
**How found:** Code review of Vault.sol signature hashing; noticed absence of chain.id in the signed data, hypothesizing cross-chain replay.
**Exploitation:** Attacker replays a user's wrong-network changeRecipientAddress signature on the correct chain, sets the recipient to an address they control (matching the user's intended address), and drains the vault funds, analogous to the Wintermute Gnosis Safe incident.
**Insight:** When auditing signature schemes, check every field that binds a signature to context (chain.id, contract address, nonce, deadline); a missing chain.id enables replay across forks/chains at identical addresses.