# Signature replay attacks for different identities (nonce on wrong party)

Ambire QuickAccManager.send omits identity from signed hash and keys nonces per identity, letting a signature for one identity be replayed on another sharing the same QuickAccount.

- Payout: Audit contest
- Severity: high
- Program: Ambire
- Found by: cmichel
- Disclosed: 2021-11-11
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2021-10-ambire-findings/issues/39
- Library page: https://bugbountylibrary.com/r/c4%3A2021-10-ambire%3AH-03
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:signature-replay

**Target:** QuickAccManager smart contract (send/cancel/execScheduled/sendTransfer/sendTxns)
**Root cause:** The signed hash excludes the identity address, and nonces are indexed per identity rather than per accHash (signer), so two fresh identities sharing one QuickAccount produce identical hashes and nonce values.
**Steps:**
1. Observe a valid `send` transaction on identity1 signed by a QuickAccount accHash.
2. Call `send` with identical arguments but replace `identity` with identity2, which also has accHash in its privileges.
3. Signature validates because identity is not in the hash and identity2's nonce is also zero; transaction executes on identity2.
4. Repeat for `cancel`, `execScheduled`, `sendTransfer`, `sendTxns`.
**How found:** Code reading of QuickAccManager.sol: noticed the design comment that one accHash can control multiple identities, then checked the signed hash construction and nonce storage and saw identity was absent from the hash and nonces were per-identity.
**Exploitation:** Attacker frontruns or replays a victim's signed transaction against a second identity sharing the same QuickAccount, e.g. duplicating a contractor payment so it is paid twice, or cancelling/executing scheduled txns on the other identity.
**Insight:** When a signer/authority can be shared across multiple target accounts, the signed payload must bind the target account address and nonces must live on the signer, not the target; otherwise fresh targets with identical nonce state yield identical hashes.