Puppy Raffle

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

[L-01] `getActivePlayerIndex()` returns 0 for non-existent players, colliding with valid index 0

Description

getActivePlayerIndex() returns 0 when a player is not found in the array. Index 0 is also a valid position for the first player who entered the raffle. Any off-chain system, frontend, or user calling this function has no way to distinguish between "this player is at position 0 in the raffle" and "this player does not exist in the raffle at all."

The intended usage pattern is: call getActivePlayerIndex() to find your position, then pass that index to refund(). A non-participant who calls getActivePlayerIndex() gets back 0 and may then call refund(0), which will revert at the msg.sender check but wastes gas and creates a confusing user experience. More importantly, a participant who is actually at index 0 has no way to programmatically verify they are truly in the raffle vs getting the default "not found" return value.

Vulnerability Details

// src/PuppyRaffle.sol, lines 110-117
function getActivePlayerIndex(address player) external view returns (uint256) {
for (uint256 i = 0; i < players.length; i++) {
if (players[i] == player) {
return i; // @> found: return actual index (could be 0)
}
}
return 0; // @> not found: also returns 0 — ambiguous!
}

Consider the following scenario:

  1. Alice enters the raffle and lands at index 0 (she was the first entrant)

  2. Alice calls getActivePlayerIndex(alice) and gets 0 — correct

  3. Bob does NOT enter the raffle

  4. Bob calls getActivePlayerIndex(bob) and also gets 0 — misleading

  5. A frontend displaying "Your raffle position: 0" shows the same thing for both Alice (who is in) and Bob (who is not)

Any smart contract integrating with PuppyRaffle that checks getActivePlayerIndex(user) >= 0 to determine participation will incorrectly conclude every address is a participant.

Risk

Likelihood:

  • This affects every call to getActivePlayerIndex() for a non-participant. Any frontend, bot, or integrating contract that relies on this function for raffle status will get ambiguous data. The function is the only public way to look up a player's index.

Impact:

  • No direct fund loss. The refund() function's require(playerAddress == msg.sender) check prevents a non-participant from actually refunding someone else's slot. The impact is limited to misleading return values, wasted gas on failed refund() attempts, and broken integrations that use 0 as a validity check.

Proof of Concept

The test demonstrates that both an active player at index 0 and a non-participant receive the same return value from getActivePlayerIndex().

function testGetActivePlayerIndex_AmbiguousZero() public {
// Enter 4 players — address(1) will be at index 0
address[] memory players = new address[](4);
players[0] = address(1);
players[1] = address(2);
players[2] = address(3);
players[3] = address(4);
puppyRaffle.enterRaffle{value: entranceFee * 4}(players);
// address(1) is a real participant at index 0
uint256 realPlayerIndex = puppyRaffle.getActivePlayerIndex(address(1));
assertEq(realPlayerIndex, 0, "Real player at index 0");
// address(99) never entered the raffle
uint256 nonPlayerIndex = puppyRaffle.getActivePlayerIndex(address(99));
assertEq(nonPlayerIndex, 0, "Non-player ALSO returns 0");
// Both return 0 — impossible to distinguish
assertEq(realPlayerIndex, nonPlayerIndex, "Ambiguous: same return for participant and non-participant");
}

Recommendations

Revert for non-existent players so callers get an unambiguous signal. This matches the pattern used by OpenZeppelin's EnumerableSet and similar lookup functions.

function getActivePlayerIndex(address player) external view returns (uint256) {
for (uint256 i = 0; i < players.length; i++) {
if (players[i] == player) {
return i;
}
}
- return 0;
+ revert("PuppyRaffle: Player not found");
}

Alternatively, return type(uint256).max as a sentinel value that cannot collide with a valid index:

- return 0;
+ return type(uint256).max;
Updates

Lead Judging Commences

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

[L-01] Ambiguous index returned from PuppyRaffle::getActivePlayerIndex(address), leading to possible refund failures

## Description The `PuppyRaffle::getActivePlayerIndex(address)` returns `0` when the index of this player's address is not found, which is the same as if the player would have been found in the first element in the array. This can trick calling logic to think the address was found and then attempt to execute a `PuppyRaffle::refund(uint256)`. ## Vulnerability Details The `PuppyRaffle::refund()` function requires the index of the player's address to preform the requested refund. ```solidity /// @param playerIndex the index of the player to refund. You can find it externally by calling `getActivePlayerIndex` function refund(uint256 playerIndex) public; ``` In order to have this index, `PuppyRaffle::getActivePlayerIndex(address)` must be used to learn the correct value. ```solidity /// @notice a way to get the index in the array /// @param player the address of a player in the raffle /// @return the index of the player in the array, if they are not active, it returns 0 function getActivePlayerIndex(address player) external view returns (int256) { // find the index... // if not found, then... return 0; } ``` The logic in this function returns `0` as the default, which is as stated in the `@return` NatSpec. However, this can create an issue when the calling logic checks the value and naturally assumes `0` is a valid index that points to the first element in the array. When the players array has at two or more players, calling `PuppyRaffle::refund()` with the incorrect index will result in a normal revert with the message "PuppyRaffle: Only the player can refund", which is fine and obviously expected. On the other hand, in the event a user attempts to perform a `PuppyRaffle::refund()` before a player has been added the EvmError will likely cause an outrageously large gas fee to be charged to the user. This test case can demonstrate the issue: ```solidity function testRefundWhenIndexIsOutOfBounds() public { int256 playerIndex = puppyRaffle.getActivePlayerIndex(playerOne); vm.prank(playerOne); puppyRaffle.refund(uint256(playerIndex)); } ``` The results of running this one test show about 9 ETH in gas: ```text Running 1 test for test/PuppyRaffleTest.t.sol:PuppyRaffleTest [FAIL. Reason: EvmError: Revert] testRefundWhenIndexIsOutOfBounds() (gas: 9079256848778899449) Test result: FAILED. 0 passed; 1 failed; 0 skipped; finished in 914.01µs ``` Additionally, in the very unlikely event that the first player to have entered attempts to preform a `PuppyRaffle::refund()` for another user who has not already entered the raffle, they will unwittingly refund their own entry. A scenario whereby this might happen would be if `playerOne` entered the raffle for themselves and 10 friends. Thinking that `nonPlayerEleven` had been included in the original list and has subsequently requested a `PuppyRaffle::refund()`. Accommodating the request, `playerOne` gets the index for `nonPlayerEleven`. Since the address does not exist as a player, `0` is returned to `playerOne` who then calls `PuppyRaffle::refund()`, thereby refunding their own entry. ## Impact 1. Exorbitantly high gas fees charged to user who might inadvertently request a refund before players have entered the raffle. 2. Inadvertent refunds given based in incorrect `playerIndex`. ## Recommendations 1. Ideally, the whole process can be simplified. Since only the `msg.sender` can request a refund for themselves, there is no reason why `PuppyRaffle::refund()` cannot do the entire process in one call. Consider refactoring and implementing the `PuppyRaffle::refund()` function in this manner: ```solidity /// @dev This function will allow there to be blank spots in the array function refund() public { require(_isActivePlayer(), "PuppyRaffle: Player is not active"); address playerAddress = msg.sender; payable(msg.sender).sendValue(entranceFee); for (uint256 playerIndex = 0; playerIndex < players.length; ++playerIndex) { if (players[playerIndex] == playerAddress) { players[playerIndex] = address(0); } } delete existingAddress[playerAddress]; emit RaffleRefunded(playerAddress); } ``` Which happens to take advantage of the existing and currently unused `PuppyRaffle::_isActivePlayer()` and eliminates the need for the index altogether. 2. Alternatively, if the existing process is necessary for the business case, then consider refactoring the `PuppyRaffle::getActivePlayerIndex(address)` function to return something other than a `uint` that could be mistaken for a valid array index. ```diff + int256 public constant INDEX_NOT_FOUND = -1; + function getActivePlayerIndex(address player) external view returns (int256) { - function getActivePlayerIndex(address player) external view returns (uint256) { for (uint256 i = 0; i < players.length; i++) { if (players[i] == player) { return int256(i); } } - return 0; + return INDEX_NOT_FOUND; } function refund(uint256 playerIndex) public { + require(playerIndex < players.length, "PuppyRaffle: No player for index"); ```

Support

FAQs

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

Give us feedback!