# QuickAccManager Smart Contract signature verification can be exploited

QuickAccManager.isValidSignature trusts an attacker-supplied identity contract in the signature, letting anyone forge a SmartWallet signature and execute arbitrary transactions to drain Ambire wallets.

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

**Target:** QuickAccManager / Identity.execute signature validation (Solidity smart contract)
**Root cause:** QuickAccManager.isValidSignature decodes an attacker-controlled `id` address from the signature and calls `Identity(id).privileges(address(this))` for the authorization check, so a malicious contract can return the expected accHash. ERC-1271's 1-contract=1-wallet assumption breaks for a singleton manager serving many identities.
**Steps:**
1. Set up target Identity with QuickAccManager registered in privileges (privileges[accHash] != 0).
2. Deploy attacker contract whose `privileges(address)` returns `keccak256(abi.encode(QuickAccount(0,0,0)))`.
3. Build `spoofedSignature = abi.encode(attackerContract, 0, 0, 0, address(quickAccountManager), SignatureMode.SmartWallet)`.
4. Call `Identity.execute(txns, spoofedSignature)`; recoverAddrImpl decodes mode=SmartWallet and calls `quickAccManager.isValidSignature(txnsHash, (attackerContract,0,0,0))`.
5. QuickAccManager computes accHash of zeroed sigs, calls attacker.privileges, gets matching hash, returns 0x1626ba7e.
6. Identity.execute privilege check passes and executes arbitrary `txns`.
**How found:** Code review of the signature flow: noticed Identity.execute forwards the raw signature to SignatureValidator and that QuickAccManager decodes `id` from that same untrusted signature, then uses it for the privileges authorization check — an attacker-controlled trust anchor.
**Exploitation:** Attacker submits Identity.execute with a SmartWallet-mode signature pointing at their own contract as the `id`; the contract returns the zero-signature accHash, the ERC-1271 check succeeds, and arbitrary transactions execute, transferring wallet funds to the attacker.
**Insight:** When a singleton signature validator is combined with ERC-1271, any identity/context address decoded from the signature itself is attacker-controlled; check whether the validator ever uses that decoded address to make an authorization decision rather than binding it to msg.sender.