Puppy Raffle

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

getActivePlayerIndex() Returns 0 for Both Index-0 Player and Not-Found

Root + Impact

Description

  • getActivePlayerIndex() returns 0 for two distinct cases:

    1. The player exists and is at index 0 in the array

    2. The player is not in the array at all

function getActivePlayerIndex(address player) external view returns (uint256) {
for (uint256 i = 0; i < players.length; i++) {
if (players[i] == player) {
return i; // @audit Returns 0 if player is at index 0
}
}
return 0; // @audit Also returns 0 if player not found
}
  • Callers (including contracts and off-chain applications) cannot distinguish between "player at index 0" and "player not found". This can lead to:

    • A non-participant accidentally calling refund(0) (which would revert with "Only the player can refund" unless they happen to be player 0)

    • Off-chain UIs displaying incorrect status for non-participants

Risk

Likelihood:

  • The first player to enter always gets index 0, so the ambiguity exists in every raffle round

Impact:

  • Low — primarily a UX/integration issue, no direct fund loss

  • Off-chain applications relying on this function may display incorrect raffle participation status

Proof of Concept

How the issue manifests:

  1. Player A enters the raffle and receives index 0 in the players array

  2. An off-chain application calls getActivePlayerIndex(playerB) where Player B has not entered the raffle

  3. The function returns 0 — the same value as Player A's actual index

  4. The application cannot determine whether Player B is at index 0 or simply not in the raffle, leading to incorrect UI state

PoC code:

function testExploit_AmbiguousPlayerIndex() public {
address[] memory players = new address[](1);
players[0] = playerOne;
puppyRaffle.enterRaffle{value: entranceFee}(players);
// playerOne is at index 0 → returns 0
uint256 indexFound = puppyRaffle.getActivePlayerIndex(playerOne);
// playerTwo is NOT in the raffle → also returns 0
uint256 indexNotFound = puppyRaffle.getActivePlayerIndex(playerTwo);
// Both return 0 — ambiguous!
assertEq(indexFound, indexNotFound, "Cannot distinguish found vs not-found");
}
// forge test --match-test testExploit_AmbiguousPlayerIndex -vvv
// Result: PASS — Both return 0, ambiguity confirmed

Expected outcome: Both a valid player at index 0 and a non-existent player return the same value (0), making it impossible for callers to distinguish between "found at index 0" and "not found".

Recommended Mitigation

The root cause is that the function uses 0 as both a valid return value (player at index 0) and a sentinel for "not found." Any ambiguous return value prevents callers from correctly distinguishing between the two states.

Option 1 (Recommended) — Revert on not-found:

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

Why this works: Reverting makes the not-found case an explicit failure, so callers (both on-chain contracts and off-chain applications) always know that a successful return is a valid index. On-chain consumers can use try/catch to handle the not-found case. This is the safest pattern because it makes misuse impossible.

Option 2 — Return a boolean alongside the index:

function getActivePlayerIndex(address player) external view returns (uint256 index, bool found) {
for (uint256 i = 0; i < players.length; i++) {
if (players[i] == player) {
return (i, true);
}
}
return (0, false);
}

Why this works: The found boolean explicitly signals whether the index is valid. Callers must check found before using index. This pattern is common in Solidity libraries (e.g., OpenZeppelin's EnumerableSet.tryGet()).

Tradeoff: Option 1 is simpler and prevents misuse by default (callers must handle the revert). Option 2 is more flexible and avoids the gas cost of revert string storage, but callers who forget to check found will silently use index 0 — the same bug in a different form. Option 1 is preferred for safety.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 8 days 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!