snek_raffle::fulfillRandomWords
is implemented to send the rewards to the winner. But if the winner address is a smart contract without any payable __default__
function will make the call to revert making the chainlink request to go in vain, making the contract gets stuck as the raffle_state
was set to calculating previously while requesting random words. Resulting in stuck contract and stuck eth of all participants without any recovery possible.
Note: If the fulfillRandomWords() implementation reverts, the VRF service will not attempt to call it a second time.
The vulnerability is present in the fulfillRandomWords
function where it has the implementation to send the rewards to the winners.
A winner being a smart contract without payable __default__
function will make the call to revert.
fulfillRandomWords
is called by chainlink VRF coordinator and this function should never revert because if it reverts it won't be called again by chainlink VRF and a new request has to be placed.
But a new request can never be placed as the raffle_state
was set to CALCULATING
and no further request can be made to VRF coordinator.
Along with that rawFulfillRandomWords
is expected to be only callable by chainlink's VRF coordinator, therefore can't be called manually.
Thus, leading the snek_raffle
contract into a totally stuck state from which no recovery is possible, and all the entrance fees of participants will be stuck forever as no winner selection request can be placed.
snek_raffle
contract will be in a stuck state with all the participant's entrance fees stuck in it and no winner selection request can be placed.
Manual Review
Prefer using pull over push method.
Modify the contracts as below:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.