The RockPaperScissors::joinGameWithEth and RockPaperScissors::joinGameWithToken functions lack a critical check to verify whether playerB has already been assigned to a game. Attackers can exploit this oversight to overwrite the existing playerB address, enabling game hijacking and frontrunning attacks. This vulnerability violates the core two-player design of the protocol and compromises game integrity.
Affected CodeThe functions directly assign msg.sender to playerB without confirming that the slot is unoccupied. This allows any address to overwrite playerB even after a legitimate player has joined the game.
Attack Scenarios
Player Hijacking:
A legitimate player (player) joins a game.
An attacker calls RockPaperScissors::joinGameWithEth/joinGameWithToken for the same gameId, replacing playerB with their own address.
Frontrunning:
A legitimate player submits a joinGame transaction.
An attacker monitors the mempool, frontruns the transaction, and replaces playerB with their own address.
Game Integrity: Legitimate players are excluded from games they intended to join.
Trust in Protocol: Users lose confidence as attackers can arbitrarily hijack games.
Add a check to ensure playerB is unassigned before allowing a player to join:
Game state remains Created after a player joins
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.