# Fallback handlers can trick users into calling functions of the AmbireAccount contract

Fallback handler functions can share a selector with AmbireAccount base functions, so a user calling an innocent-looking handler silently invokes setAddrPrivilege and hands wallet control to an attacker.

- Payout: Audit contest
- Severity: medium
- Program: Ambire
- Found by: adriro
- Disclosed: 2023-08-04
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2023-05-ambire#m-01
- Library page: https://bugbountylibrary.com/r/c4%3A2023-05-ambire%3AM-01
- Tags: area:web3 domain:web3 impact:funds-loss impact:privesc kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** Smart contract wallet (AmbireAccount) fallback handler dispatch
**Root cause:** Solidity dispatches by 4-byte selector only; a fallback handler function can be crafted with a signature whose selector collides with a privileged base AmbireAccount function, so the call is routed to the base contract function instead of the handler.
**Steps:**
1. Identify a privileged base function in AmbireAccount, e.g. `setAddrPrivilege(address,bytes32)`.
2. Compute its 4-byte selector from the signature.
3. Brute-force a different function signature (innocent-looking name/args) whose keccak selector matches.
4. Deploy a fallback handler exposing that colliding function with a harmless-looking implementation.
5. Get the handler registered/opted into by a user; when the user calls the handler function, dispatch resolves to the base `setAddrPrivilege` and grants the attacker control.
**How found:** Reasoning from Solidity's selector-based dispatch: since fallback handlers extend the wallet via fallback(), any handler function selector can be made to collide with a base contract function, hiding a privileged call behind an innocent signature.
**Exploitation:** Attacker must convince Ambire wallet users to opt into a malicious fallback handler. The handler exposes a function whose selector collides with a base AmbireAccount function; a user invoking the seemingly benign handler function actually executes the base privileged function (e.g. setAddrPrivilege), transferring wallet control to the attacker.
**Insight:** When a contract routes unknown selectors to pluggable handlers, check whether handler function selectors can collide with privileged base-contract selectors; brute-forcing a 4-byte collision is cheap and lets a benign-looking handler entry point silently execute admin functions.