Summary

The receive() function allows users to send Ether, but it does not check whether the sender is already a participant. This leads to the sender being considered a new participant without considering their previous participation status. It should align with the logic in the deposit() function, where the participant's status is verified before deciding whether to treat the deposit as a contribution or a new signup.

Vulnerability Details

• Lack of Participant Check: The receive() function directly adds the Ether to the sender's balance and treats it as a new signup without checking whether the sender is already a participant. This bypasses the logic in the deposit() function, where the system distinguishes between a "Generous Additional Contribution" and a new participant signup.

• Inconsistent Behavior: This inconsistency could confuse users or result in a mismatch between the expected behavior (such as allowing users to contribute more after they’ve signed up) and the actual behavior (treating all deposits as new signups).

Impact

• Incorrect Participant Status: A user who has already signed up as a participant could unintentionally be treated as a new participant, disrupting the contract’s state and potentially causing issues with the logic of signups and contributions.

• User Confusion: Users could be confused about their participation status, especially if they are already a participant but are treated as a new participant after depositing Ether.

Tools Used

• Manual code review

Recommendations

To fix this issue, the receive() function should check if the sender is already a participant, just like the deposit() function does. If the sender is a participant, treat the deposit as a "Generous Additional Contribution." If not, treat it as a new signup.

Here’s the corrected version of the receive() function: