The proposal replay attack vulnerability arises because the contract does not check for duplicate proposals. This allows an attacker to repeatedly submit the same proposal, which could lead to network spam, governance inefficiencies, and potential denial-of-service (DoS) attacks.
The contract does not maintain a record of past proposal hashes to prevent duplicate proposals.
The proposalId
is incremented sequentially (uint256 proposalId = _proposalCount++
), meaning identical proposals will always be accepted with different IDs.
An attacker can continuously submit the same proposal, congesting the governance system and spamming voters with redundant proposals.
If the contract has limits on active proposals or voting resources, it could prevent legitimate proposals from being processed.
Governance Spam: The system could be flooded with identical proposals, overwhelming voters and making governance less effective.
Denial-of-Service (DoS): Attackers could exploit gas or storage limits to prevent the submission of legitimate proposals.
Vote Dilution: If resources for proposal processing are limited, it may prevent other users from submitting meaningful proposals.
Manual Review
Enforce Proposal Uniqueness: Store a mapping of keccak256(abi.encode(targets, values, calldatas, description))
to prevent duplicate proposals.
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.