[H-2] Weak randomness in PuppyRaffle::selectWinner allows anyone to influence or predict the winner

Description

Hashing msg.sender, block.timestamp, and block.prevrandao together to determine a winner creates a predictable outcome. None of these values are truly random — they are either known ahead of time or directly controllable by the caller or a validator.

A malicious user can simulate this exact computation off-chain before submitting their transaction, and either time their call or manipulate msg.sender (via a contract with a chosen address) to land on a winning index. The same vulnerability applies to the rarity calculation:

Since both the winner selection and rarity assignment use the same predictable inputs, an attacker can guarantee both winning the raffle and minting the rarest puppy in the same transaction.

Risk

Impact: High — an attacker can steal the entire prize pool and guarantee legendary rarity on every run.

Likelihood: High — this requires no special access, no funds beyond the entrance fee, and is a well-documented attack in the Ethereum ecosystem. Any technically capable participant can exploit this.

Proof of Concept

There are several attack vectors:

1. Validator manipulation

Validators know block.timestamp and block.prevrandao before the block is published. A validator who is also a raffle participant can selectively propose or withhold blocks until the computed winnerIndex lands on their own address. See the Solidity blog on prevrandao for a detailed breakdown of this attack.

2. msg.sender manipulation

A malicious user can deploy a contract, compute the winning msg.sender off-chain, and call selectWinner from that address. Since msg.sender is fully controlled by the attacker, they can brute-force a contract address (via CREATE2) that produces a winning index.

3. Timestamp manipulation

Miners and validators have limited but real influence over block.timestamp (within ~15 seconds). Combined with knowledge of block.prevrandao, this narrows the winning conditions to a computable range.

4. Full simulation attack

An attacker can simply simulate the selectWinner call at different timestamps off-chain using eth_call, iterating until they find a timestamp that produces their desired winner index, then submit the transaction timed to that block.

Using on-chain values as a randomness seed is a well-known attack vector in the blockchain space and should never be used in production for anything of value.

Recommended Mitigation

Use a cryptographically verifiable random number generator such as Chainlink VRF. This provides randomness that is provably unmanipulable by any on-chain actor, including validators.

The winner selection and rarity assignment should both be moved into the VRF callback fulfillRandomWords, ensuring neither value can be predicted or influenced before the randomness is committed on-chain.