# An owner can be censored by another owner with a lower address

In Optimism's LivenessGuard, a malicious Safe owner with a lower address can append their signature to a proposal, causing a higher-address victim's signature to be ignored and their liveness not updated, leading to their removal.

- Payout: Contest reward
- Severity: medium
- Program: Optimism
- Credited: zigtur
- Disclosed: 2024-06-06
- Write-up quality: 7/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_optimism_may2024.pdf#3.1.1
- Library page: https://bugbountylibrary.com/r/cantina%3Aoptimism_may2024%3A3.1.1
- Tags: domain:web3 impact:dos kind:contest platform:cantina sev:medium tech:solidity technique:chained vuln:business-logic

**Target:** LivenessGuard smart contract (Safe module)
**Root cause:** LivenessGuard.checkTransaction uses SafeSigners.getNSigners which only processes the first `threshold` signatures, ignoring any extra signatures even if they are valid. Combined with Safe's requirement that signatures be sorted ascendingly by owner address, an attacker with a lower address can insert their signature before the victim's, pushing the victim's signature beyond the threshold and preventing their liveness from being recorded.
**Steps:**
1. Deploy a Safe with 13 owners and threshold 10, including attacker (address 0x7777...) and victim (address 0xEEEE...).
2. Wait for a transaction to have 10 signatures, including the victim's, but not the attacker's.
3. Attacker signs the transaction, making it 11 signatures.
4. Because signatures must be sorted ascendingly, the attacker's signature (lower address) is placed before the victim's, and only the first 10 are processed by SafeSigners.getNSigners.
5. The victim's signature is ignored, so LivenessGuard does not update lastLive[victim].
6. If the victim does not call showLiveness() separately, they can be removed from the owners list for inactivity.
**How found:** The researcher combined the specification that extra signatures are ignored with the Safe requirement that signatures be sorted ascendingly by owner address, realizing that a lower-address owner could censor a higher-address owner by adding an extra signature.
**Exploitation:** An attacker owner monitors proposals and waits until the victim has signed but the attacker hasn't. The attacker then signs, adding an extra signature. Due to ascending address ordering, the attacker's signature is placed before the victim's, and only the first `threshold` signatures are considered. The victim's liveness is not updated, allowing the attacker to later remove the victim for inactivity.
**Insight:** When a contract processes only a subset of provided signatures (e.g., first N), and ordering is enforced, an attacker can manipulate the set of processed signers by adding extra signatures. Always verify all provided signatures or ensure that liveness tracking accounts for all signers.