When you revoke a signer, their "yes" votes on pending transactions should be removed, and those transactions should only execute if enough currently active signers have confirmed them.
Revoked signers' "yes" votes remain counted, and transactions can execute using those invalid votes because the execution function doesn't check whether the confirming signers are still authorized.
Likelihood:
This is not a complex attack requiring multiple conditions. It's a direct consequence of the code logic:
Signer confirms transaction → Confirmation count increases
Signer gets revoked → Confirmation count remains unchanged
Transaction executes → Uses stale confirmation count
An attacker could:
Join as a signer
Confirm many transactions (legitimate and potentially malicious)
Get revoked for suspicious behavior
Still have their confirmations count toward execution
Impact:
The fundamental principle of multisig wallets is that only currently authorized signers can approve transactions. This vulnerability allows revoked signers to continue influencing transaction execution.
Transactions can execute with confirmations from signers who are no longer authorized, potentially leading to:
Execution of transactions that shouldn't meet the threshold
Bypass of governance controls
Loss of funds if revoked signers had malicious intent
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.
The contest is complete and the rewards are being distributed.