Rock Paper Scissors
First Flight #38
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Severity: medium
Invalid

Missing Zero Address Validation in ETH Refund Logic

shreyash20032

Summary

The _cancelGame function contains a logic flaw where it transfers ETH to playerA without validating that the address is not zero. This creates a critical edge case where, if playerA is address(0), the contract will send ETH to an unrecoverable address, resulting in permanent fund loss. A simple check for address(0) before refunding would mitigate this issue.

Vulnerability Details

When a game is canceled, the contract refunds ETH to both playerA and playerB. The code checks if playerB is not the zero address before processing the transfer, but no such check exists for playerA:

if (game.bet > 0) { (bool successA,) = game.playerA.call{value: game.bet}(""); require(successA, "Transfer to player A failed"); if (game.playerB != address(0)) { (bool successB,) = game.playerB.call{value: game.bet}(""); require(successB, "Transfer to player B failed"); } }

If game.playerA is ever address(0) (e.g., due to an error in game creation or a malicious interaction), ETH will be sent to the zero address, resulting in irreversible loss.

Impact

Loss of funds due to sending ETH to address(0)

  • Could be exploited or triggered unintentionally

  • Damages user trust and affects contract integrity

Tools Used

Manual Review

Recommendations

Before making the refund to playerA, add a check similar to playerB:

if (game.bet > 0) {
if (game.playerA != address(0)) {
(bool successA,) = game.playerA.call{value: game.bet}("");
require(successA, "Transfer to player A failed");
}
​
if (game.playerB != address(0)) {
(bool successB,) = game.playerB.call{value: game.bet}("");
require(successB, "Transfer to player B failed");
}
}
Updates

Appeal created

m3dython Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational

Code suggestions or observations that do not pose a direct security risk.

m3dython Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational

Code suggestions or observations that do not pose a direct security risk.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.