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 Code
The 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.