Winner selection uses manipulable on-chain values, allowing the caller to bias the raffle outcome

Affected Contract

src/PuppyRaffle.sol

Affected Code

selectWinner derives randomness from msg.sender, block.timestamp, and block.difficulty.

Rarity is also derived from msg.sender and block.difficulty.

Description

The raffle uses predictable and influenceable values as randomness. selectWinner is permissionless, so the caller is part of the random seed. An attacker can search for a caller address that produces a desired winnerIndex, then call selectWinner from that address when the known block values match the calculation.

Block producers have even stronger influence because they can affect timestamp and transaction ordering. This breaks the core raffle guarantee that winners and NFT rarity are fairly random.

Risk

The raffle outcome can be steered by a participant or transaction sender instead of being random. This lets an attacker unfairly capture the prize pool, mint the puppy NFT to a chosen winner, and potentially influence rare NFT traits.

Impact

High. A participant can bias or force the winner selection and capture the prize pool and puppy NFT unfairly. The same randomness weakness can also bias NFT rarity.

Likelihood

Medium. The attack depends on controlling or preparing the caller address and timing the draw, but the function is permissionless and all seed inputs are public or influenceable.

Proof of Concept

Added test: test/AuditFindings.t.sol

Run:

The test:

1. Four players enter the raffle.

2. The raffle duration passes.

3. The test searches for a caller address that makes winnerIndex == 0.

4. Calling selectWinner from that address makes playerOne the winner.

Recommended Mitigation

Use a verifiable randomness source such as Chainlink VRF. If a two-step flow is needed, separate the request and fulfillment phases so users cannot choose the final seed at draw time.

Do not include msg.sender, block.timestamp, or block.difficulty as the only entropy source for economically meaningful randomness.

Example mitigation pattern:

The important security property is that the final random value is provided by the VRF coordinator after the request, not chosen from caller-controlled or block-producer-influenceable inputs inside selectWinner.