Puppy Raffle

AI First Flight #1
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Submission Details
Severity: high
Valid

M-01: Players can front-run selectWinner() with refunds after learning outcomes

Root + Impact

Description

  • Normal behavior: Refunds should not allow participants to mutate the draw set/accounting at the moment the raffle is drawn.

  • Specific issue: refund() is callable up until selectWinner() execution. By front-running the draw with refund(), a participant can create address(0) slots (L103) while selectWinner() uses players.length and players[winnerIndex] without filtering, causing correctness/liveness issues.

@> PuppyRaffle.sol:L96-L105 (refund creates blank spots)
96: function refund(uint256 playerIndex) public {
101: payable(msg.sender).sendValue(entranceFee);
@>103: players[playerIndex] = address(0);
@> PuppyRaffle.sol:L127-L133 (selectWinner uses players.length and array contents as-is)
@>127: require(players.length >= 4, "PuppyRaffle: Need at least 4 players");
@>130: address winner = players[winnerIndex];
@>131: uint256 totalAmountCollected = players.length * entranceFee;

Risk

Likelihood:

  • Reason 1 Public mempool allows ordering games; refund() can be mined immediately before selectWinner().

  • Reason 2 SelectWinner() uses players[] directly (L130-L131), so late refunds impact draw behavior.

Impact:

  • Impact 1 When this will occur: During the draw window: after raffle end time and before/during the mined selectWinner() transaction.

  • Impact 2 Winner selection and accounting can become inconsistent (holes, wrong totals).

  • Impact 3 The round can be griefed (reverts or incorrect payouts/mints), reducing protocol liveness.

Proof of Concept

Goal: Deny service by making enterRaffle() exceed gas limits as players grows.
Relevant lines:
@> enterRaffle(): PuppyRaffle.sol:L86-L89 compares every pair in players[] (O(n^2)).
PoC:
1) Call enterRaffle() repeatedly to grow players[] (PuppyRaffle.sol:L81-L83).
2) Each call triggers the nested loops at L86-L89 across the full players[] array.
3) Gas grows quadratically; eventually enterRaffle() becomes too expensive and reverts, blocking new

Recommended Mitigation

Replace duplicate checks with mapping(address => bool) hasEntered for O(1) checks.
• Maintain per-round membership mapping and clear it when resetting the round (when players is deleted).
• Avoid nested loops over dynamic arrays on the write-path.
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 12 days ago
Submission Judgement Published
Validated
Assigned finding tags:

[H-04] `PuppyRaffle::refund` replaces an index with address(0) which can cause the function `PuppyRaffle::selectWinner` to always revert

## Description `PuppyRaffle::refund` is supposed to refund a player and remove him from the current players. But instead, it replaces his index value with address(0) which is considered a valid value by solidity. This can cause a lot issues because the players array length is unchanged and address(0) is now considered a player. ## Vulnerability Details ```javascript players[playerIndex] = address(0); @> uint256 totalAmountCollected = players.length * entranceFee; (bool success,) = winner.call{value: prizePool}(""); require(success, "PuppyRaffle: Failed to send prize pool to winner"); _safeMint(winner, tokenId); ``` If a player refunds his position, the function `PuppyRaffle::selectWinner` will always revert. Because more than likely the following call will not work because the `prizePool` is based on a amount calculated by considering that that no player has refunded his position and exit the lottery. And it will try to send more tokens that what the contract has : ```javascript uint256 totalAmountCollected = players.length * entranceFee; uint256 prizePool = (totalAmountCollected * 80) / 100; (bool success,) = winner.call{value: prizePool}(""); require(success, "PuppyRaffle: Failed to send prize pool to winner"); ``` However, even if this calls passes for some reason (maby there are more native tokens that what the players have sent or because of the 80% ...). The call will thankfully still fail because of the following line is minting to the zero address is not allowed. ```javascript _safeMint(winner, tokenId); ``` ## Impact The lottery is stoped, any call to the function `PuppyRaffle::selectWinner`will revert. There is no actual loss of funds for users as they can always refund and get their tokens back. However, the protocol is shut down and will lose all it's customers. A core functionality is exposed. Impact is high ### Proof of concept To execute this test : forge test --mt testWinnerSelectionRevertsAfterExit -vvvv ```javascript function testWinnerSelectionRevertsAfterExit() public playersEntered { vm.warp(block.timestamp + duration + 1); vm.roll(block.number + 1); // There are four winners. Winner is last slot vm.prank(playerFour); puppyRaffle.refund(3); // reverts because out of Funds vm.expectRevert(); puppyRaffle.selectWinner(); vm.deal(address(puppyRaffle), 10 ether); vm.expectRevert("ERC721: mint to the zero address"); puppyRaffle.selectWinner(); } ``` ## Recommendations Delete the player index that has refunded. ```diff - players[playerIndex] = address(0); + players[playerIndex] = players[players.length - 1]; + players.pop() ```

Support

FAQs

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

Give us feedback!