Core Contracts

Summary

The recordVote function in the contract allows any external caller to record a vote on behalf of any voter. There is no access control or check to ensure that the vote is being recorded by the voter themselves. This flaw could lead to unauthorized and fraudulent vote recording in governance proposals.

Vulnerability Details

The recordVote function is implemented as follows:

Key issues include:

• Lack of Access Control:
  The function accepts a voter parameter and does not verify that msg.sender is the same as voter. This oversight allows any external actor to submit votes on behalf of other addresses.

• Potential for Vote Fraud:
  By exploiting this function, an attacker can record votes for any voter, bypassing the intended one-vote-per-voter mechanism. Even though the mapping _hasVotedOnProposal prevents a single address from voting multiple times for the same proposal, an attacker can still record a vote for a victim without their consent.

Impact

• Compromised Governance Integrity:
  Unauthorized vote recording could alter the outcome of governance proposals by inflating or misrepresenting the voting power of certain addresses.

• Unfair Influence:
  Attackers could potentially manipulate voting results, undermining the democratic process and confidence in the protocol's governance system.

Tools Used

• Manual code review

Recommended Mitigation

• Restrict Vote Recording to the Voter:
  Modify the recordVote function to ensure that the caller is the same as the voter. For example, add a check:

  require(msg.sender == voter, "Unauthorized: caller is not the voter");

  This ensures that only the owner of the voting power can record their vote.

• Consider Removing the voter Parameter:
  Alternatively, remove the voter parameter altogether and assume that the vote is always recorded on behalf of msg.sender. This approach inherently prevents unauthorized vote recording.