Summary

The participant mapping should be updated inside refund() function to prevent a replay attack.

Vulnerability Details

If the participant[msg.sender] flag is not set to false after the first refund, the same participant can call the refund function again. While the _refundERC20 and _refundETH functions won’t transfer additional funds due to balances being zero, the emit Refunded(msg.sender) line will still execute. As well as if he wants to deposit funds again it will emit GenerousAdditionalContributioninplace of NewSignup

Impact

This will result is a series of false emits being emitted by the contract leading to confusions/misleading information to the protocol users/observers that someone refunded multiple times and/or fake additional contributions.

Tools Used

Manual Review

Recommendations

Update the participant[msg.sender] to false in the refund() function. And add a check at the beginning to check if the msg.sender is a participant or not(This check has been already mentioned in the given report.md)