refund() should return exactly one entranceFee to an active player and then mark that player's slot as refunded (address(0)), so the same ticket cannot be refunded a second time and other players' deposits stay in the contract.
refund() sends ETH with payable(msg.sender).sendValue(entranceFee) at L101 and only clears the slot with players[playerIndex] = address(0) at L103, and the contract has no reentrancy guard. OpenZeppelin 3.4.0 Address.sendValue uses recipient.call{value: amount}("") and forwards all gas, so a contract player's receive() can call refund(playerIndex) again while players[playerIndex] still equals msg.sender. The checks at L98-L99 pass on every re-entry, and the loop only ends when the contract balance falls below entranceFee.
Likelihood:
Any account can trigger it at any time during an open round: enterRaffle() accepts contract addresses, the attacker needs only one entranceFee, and getActivePlayerIndex() returns the slot index.
It happens whenever the contract holds at least one entranceFee beyond the attacker's own deposit, which is the normal state while other players are entered or fees are still unwithdrawn.
The attack is a single transaction with a short receive() hook; it needs no privileged role, no timing, and no special market conditions.
Impact:
Direct theft of other players' deposits: in the PoC, 4 honest players deposit 4 ETH and an attacker who pays 1 ETH leaves with 5 ETH, with the raffle balance at 0.
Theft of accrued, unwithdrawn protocol fees, which sit in the same balance: in the PoC the attacker takes 3 ETH for 1 ETH paid out of a 3.8 ETH balance that includes 0.8 ETH of round-1 fees. Only a remainder smaller than one entranceFee (0.8 ETH there) is left.
The contract becomes insolvent for the rest of the round: an honest player's refund then reverts with "Address: insufficient balance", so remaining players cannot recover their entrance fees.
The PoC adds a ReentrantRefunder contract that enters the raffle with one ticket and calls refund() again from receive() while the raffle still holds at least one entranceFee. test_baseline_refundPaysOnce shows the intended behavior: one honest refund pays exactly 1 ETH and a second refund of the same slot reverts. test_reentrancy_drainsAllDeposits asserts that after 4 honest 1 ETH entries the attacker gets 5 refunds from one ticket, the raffle balance is 0, and the attacker holds 5 ETH. test_reentrancy_stealsAccruedFeesAndBricksRound asserts that the attacker takes 3 ETH from a balance that includes 0.8 ETH of accrued fees, leaving 0.8 ETH, and that an honest player's refund then reverts with "Address: insufficient balance". Run it with: forge test --match-path test/PoC_PR-01.t.sol -vvv
File test/PoC_PR-01.t.sol; run FOUNDRY_FFI=false forge test --match-path test/PoC_PR-01.t.sol -vv.
## Description The `PuppyRaffle::refund()` function doesn't have any mechanism to prevent a reentrancy attack and doesn't follow the Check-effects-interactions pattern ## Vulnerability Details ```javascript function refund(uint256 playerIndex) public { address playerAddress = players[playerIndex]; require(playerAddress == msg.sender, "PuppyRaffle: Only the player can refund"); require(playerAddress != address(0), "PuppyRaffle: Player already refunded, or is not active"); payable(msg.sender).sendValue(entranceFee); players[playerIndex] = address(0); emit RaffleRefunded(playerAddress); } ``` In the provided PuppyRaffle contract is potentially vulnerable to reentrancy attacks. This is because it first sends Ether to msg.sender and then updates the state of the contract.a malicious contract could re-enter the refund function before the state is updated. ## Impact If exploited, this vulnerability could allow a malicious contract to drain Ether from the PuppyRaffle contract, leading to loss of funds for the contract and its users. ```javascript PuppyRaffle.players (src/PuppyRaffle.sol#23) can be used in cross function reentrancies: - PuppyRaffle.enterRaffle(address[]) (src/PuppyRaffle.sol#79-92) - PuppyRaffle.getActivePlayerIndex(address) (src/PuppyRaffle.sol#110-117) - PuppyRaffle.players (src/PuppyRaffle.sol#23) - PuppyRaffle.refund(uint256) (src/PuppyRaffle.sol#96-105) - PuppyRaffle.selectWinner() (src/PuppyRaffle.sol#125-154) ``` ## POC <details> ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.7.6; import "./PuppyRaffle.sol"; contract AttackContract { PuppyRaffle public puppyRaffle; uint256 public receivedEther; constructor(PuppyRaffle _puppyRaffle) { puppyRaffle = _puppyRaffle; } function attack() public payable { require(msg.value > 0); // Create a dynamic array and push the sender's address address[] memory players = new address[](1); players[0] = address(this); puppyRaffle.enterRaffle{value: msg.value}(players); } fallback() external payable { if (address(puppyRaffle).balance >= msg.value) { receivedEther += msg.value; // Find the index of the sender's address uint256 playerIndex = puppyRaffle.getActivePlayerIndex(address(this)); if (playerIndex > 0) { // Refund the sender if they are in the raffle puppyRaffle.refund(playerIndex); } } } } ``` we create a malicious contract (AttackContract) that enters the raffle and then uses its fallback function to repeatedly call refund before the PuppyRaffle contract has a chance to update its state. </details> ## Recommendations To mitigate the reentrancy vulnerability, you should follow the Checks-Effects-Interactions pattern. This pattern suggests that you should make any state changes before calling external contracts or sending Ether. Here's how you can modify the refund function: ```javascript function refund(uint256 playerIndex) public { address playerAddress = players[playerIndex]; require(playerAddress == msg.sender, "PuppyRaffle: Only the player can refund"); require(playerAddress != address(0), "PuppyRaffle: Player already refunded, or is not active"); // Update the state before sending Ether players[playerIndex] = address(0); emit RaffleRefunded(playerAddress); // Now it's safe to send Ether (bool success, ) = payable(msg.sender).call{value: entranceFee}(""); require(success, "PuppyRaffle: Failed to refund"); } ``` This way, even if the msg.sender is a malicious contract that tries to re-enter the refund function, it will fail the require check because the player's address has already been set to address(0).Also we changed the event is emitted before the external call, and the external call is the last step in the function. This mitigates the risk of a reentrancy attack.
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.