# Other module can add owners to safe that push us above maxSigners, bricking safe

An external Safe module can add owners beyond maxSigners; reconcileSignerCount then reverts every transaction, permanently bricking the HatsSignerGate safe and freezing funds.

- Payout: Contest reward
- Severity: high
- Program: Hats
- Credited: obront
- Disclosed: 2023-02-15
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-02-hats-judging/issues/46
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-hats%3AH-5
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:dos

**Target:** HatsSignerGate / HatsSignerGateBase Safe module (Solidity)
**Root cause:** claimSigner() enforces maxSigners, but owners added by other Safe modules bypass that check; reconcileSignerCount() reverts with MaxSignersReached whenever validSignerCount > maxSigners, and there is no mechanism to reduce signers.
**Steps:**
1. Deploy a Safe with HatsSignerGate module plus another module capable of adding owners (e.g. via enableModule/execTransaction).
2. Use the second module to add more hat-wearing addresses as Safe owners than maxSigners allows.
3. Any subsequent Safe transaction calls checkTransaction() -> reconcileSignerCount(), which hits `if (validSignerCount > maxSigners) { revert MaxSignersReached(); }`.
4. All transactions revert; if the hat is immutable and eligibility is not admin-controlled, hats cannot be burned/transferred, so the safe stays bricked unless wearers renounce.
**How found:** Code reading of HatsSignerGateBase: noticed maxSigners is only enforced in claimSigner(), while reconcileSignerCount() reverts on excess valid signers, and reasoned that other Safe modules adding owners bypass the claimSigner check.
**Exploitation:** Precondition: a second module on the Safe that can add owners. Attacker (or accidental config) adds >maxSigners hat wearers as owners; every checkTransaction reverts, freezing all funds and blocking all Safe operations.
**Insight:** When a guard/module enforces invariants only on its own write path, check whether co-installed modules can mutate the same state (Safe owners) outside that path; a revert-on-invariant-violation in a transaction guard turns any excess into a permanent DoS.