refund() should return a player's entranceFee and take their ticket out of the round. selectWinner() should then pay 80% of the ETH actually collected from active tickets to a winner chosen among active players and book the other 20% in totalFees. That keeps address(this).balance equal to totalFees after each draw, so withdrawFees can pay the fees out.
refund() pays back entranceFee but only overwrites the player's slot with address(0), so players.length does not shrink. selectWinner() uses players.length for the 4-player gate, for the winner-index modulus and for totalAmountCollected = players.length * entranceFee. Each refunded slot therefore overstates the round's funds by entranceFee: 80% of that is paid to the winner out of other ETH held by the contract (accrued fees), and 20% is added to totalFees with no ETH behind it, which breaks the strict balance == totalFees check in withdrawFees.
Likelihood:
The bug triggers in every round where at least one player calls refund() before selectWinner(). Refunds are an advertised feature (contract natspec point 3), so ordinary use is enough and no attacker is needed.
Accrued fees sit in the contract from each draw until withdrawFees is called. After the first refund-affected draw, withdrawFees keeps reverting, so the fee reserve that later blank slots draw on only grows.
selectWinner() is permissionless. The theft path needs only the attacker's own addresses and enough ETH to enter them; every ticket except one is refunded. Blank-slot draws revert in _safeMint, so the only draw that can succeed pays the attacker's live slot.
Impact:
Protocol fees are paid out as prize money. Each refunded slot moves 0.8 * entranceFee from the fee reserve to the winner. In the PoC, with 4 ETH of accrued fees, an attacker enters 6 addresses, refunds 5, wins 4.8 ETH and nets +3.8 ETH. The draw runs with a single real player because blank slots satisfy the >= 4 gate.
After a round with k refunds, totalFees exceeds the balance by k * entranceFee (PoC: 1.8 ETH booked against 0.8 ETH held), so withdrawFees reverts. Refund-free rounds add equally to both sides: the PoC shows the 1 ETH gap unchanged after a later clean round. The gap closes only through a forced ETH send, or when active players' deposits happen to fill it. In that case withdrawFees sends those deposits to feeAddress, and the player's refund then reverts (PoC: victim's 1 ETH swept, refund fails with 'Address: insufficient balance').
When more than 20% of a round's slots are refunded and no reserve covers the inflated prize, every selectWinner call reverts with 'Failed to send prize pool to winner'. New entries also revert with 'Duplicate player', because the two address(0) slots compare equal. The round cannot be settled unless ETH is force-sent into the contract.
test/PoC_PR-03.t.sol deploys PuppyRaffle with a 1 ETH entrance fee. It makes draws deterministic by picking a msg.sender that maps to a chosen winner index under selectWinner's own formula. The tests check five cases: (1) a no-refund baseline in which fees withdraw normally; (2) one ordinary refund that leaves players.length at 5, pays the winner 4 ETH from a 4.8 ETH balance and leaves 0.8 ETH against totalFees of 1.8 ETH, so withdrawFees reverts, and the 1 ETH gap survives a later clean round; (3) the 6-enter/5-refund theft netting +3.8 ETH of accrued fees, where a draw that lands on a blank slot reverts in _safeMint; (4) withdrawFees sweeping an active player's deposit; and (5) an unsettleable round. Run it with forge test --match-path test/PoC_PR-03.t.sol -vv.
File test/PoC_PR-03.t.sol; run FOUNDRY_FFI=false forge test --match-path test/PoC_PR-03.t.sol -vv.
## 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() ```
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.