Inconsistent State Between s_isSigner Mapping and AccessControl Roles
The contract maintains two separate sources of truth for signer status: the s_isSigner mapping and the AccessControl SIGNING_ROLE. While these are updated together in normal operations, there's no guarantee they remain synchronized. The contract uses s_isSigner for validation in revokeSigningRole but SIGNING_ROLE for actual permission checks. If these become desynchronized (e.g., through direct AccessControl manipulation if the contract is upgraded or through inheritance issues), it could lead to authorization bypasses
Likelihood:
When the contract were to add functionality that directly calls AccessControl's grantRole without updating s_isSigner, or if there's an upgrade path that doesn't properly migrate both states, an attacker could gain signing privileges without being tracked in the signer array.
Impact:
Users could potentially confirm/execute transactions without being in the s_signers array, or legitimate signers could be prevented from acting if the two systems desynchronize.
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.