`SnowmanAirdrop::claimSnowman` never reads `s_hasClaimedSnowman`, so a claim can be replayed indefinitely with the same proof and the same signature
Root + Impact
Description
-
Each whitelisted address is meant to claim its allocation once; the contract tracks this in
s_hasClaimedSnowmanand exposes it throughgetClaimStatus(). -
However,
claimSnowmanonly writes that mapping and never reads it, and the EIP-712 digest is a pure function of(receiver, balance)with no nonce or deadline, so the byte-for-byte identical proof and(v, r, s)stay valid and can be resubmitted.
Risk
Likelihood:
-
Every time a receiver's
Snowbalance returns to its leaf amount, which happens on its own through the free weeklyearnSnow(). -
Every time an attacker reuses a signature observed in a past claim transaction, since
claimSnowmanaccepts any caller and the digest never expires. The proofs are public by design, published inscript/flakes/output.json.
Impact:
Every whitelisted address mints its allocation an unlimited number of times through the airdrop itself, breaking the 1:1 relationship between staked
Snowand NFTs. GatingSnowman::mintSnowmandoes not help, since the mint comes from the authorised caller.An attacker repeatedly forces a victim's
Snowinto the airdrop contract, where it is unrecoverable, without the victim ever initiating a claim.
Proof of Concept
Alice claims normally, re-earns the same balance for free a week later, then replays the same proof and the same signature. AL_PROOF is her proof from the project's generated output.json, and her balance after Helper setup is 1.
Recommended Mitigation
Read the flag that is already being written, set it before the external calls to restore checks-effects-interactions, and bind the signature to a per-receiver nonce and an expiry so it cannot outlive a single claim. The typehash and the struct must change together with getMessageHash, otherwise the new members stay outside the signed digest.
getMessageHash must take deadline and read s_nonces[receiver] into the digest. The increment has to run after the signature is verified — incrementing earlier makes the contract check a nonce the signer never signed, reverting every claim. The deadline is not redundant next to the claimed flag: without it a harvested signature stays usable indefinitely, letting a third party force the claim, and the victim's token transfer, at a time of their choosing.
Lead Judging Commences
[L-01] Missing Claim Status Check Allows Multiple Claims in SnowmanAirdrop.sol::claimSnowman
# Root + Impact   **Root:** The [`claimSnowman`](https://github.com/CodeHawks-Contests/2025-06-snowman-merkle-airdrop/blob/b63f391444e69240f176a14a577c78cb85e4cf71/src/SnowmanAirdrop.sol#L44) function updates `s_hasClaimedSnowman[receiver] = true` but never checks if the user has already claimed before processing the claim, allowing users to claim multiple times if they acquire more Snow tokens. **Impact:** Users can bypass the intended one-time airdrop limit by claiming, acquiring more Snow tokens, and claiming again, breaking the airdrop distribution model and allowing unlimited NFT minting for eligible users. ## Description * **Normal Behavior:** Airdrop mechanisms should enforce one claim per eligible user to ensure fair distribution and prevent abuse of the reward system. * **Specific Issue:** The function sets the claim status to true after processing but never validates if `s_hasClaimedSnowman[receiver]` is already true at the beginning, allowing users to claim multiple times as long as they have Snow tokens and valid proofs. ## Risk **Likelihood**: Medium * Users need to acquire additional Snow tokens between claims, which requires time and effort * Users must maintain their merkle proof validity across multiple claims * Attack requires understanding of the missing validation check **Impact**: High * **Airdrop Abuse**: Users can claim far more NFTs than intended by the distribution mechanism * **Unfair Distribution**: Some users receive multiple rewards while others may receive none * **Economic Manipulation**: Breaks the intended scarcity and distribution model of the NFT collection ## Proof of Concept Add the following test to TestSnowMan.t.sol ```Solidity function testMultipleClaimsAllowed() public { // Alice claims her first NFT vm.prank(alice); snow.approve(address(airdrop), 1); bytes32 aliceDigest = airdrop.getMessageHash(alice); (uint8 v, bytes32 r, bytes32 s) = vm.sign(alKey, aliceDigest); vm.prank(alice); airdrop.claimSnowman(alice, AL_PROOF, v, r, s); assert(nft.balanceOf(alice) == 1); assert(airdrop.getClaimStatus(alice) == true); // Alice acquires more Snow tokens (wait for timer and earn again) vm.warp(block.timestamp + 1 weeks); vm.prank(alice); snow.earnSnow(); // Alice can claim AGAIN with new Snow tokens! vm.prank(alice); snow.approve(address(airdrop), 1); bytes32 aliceDigest2 = airdrop.getMessageHash(alice); (uint8 v2, bytes32 r2, bytes32 s2) = vm.sign(alKey, aliceDigest2); vm.prank(alice); airdrop.claimSnowman(alice, AL_PROOF, v2, r2, s2); // Second claim succeeds! assert(nft.balanceOf(alice) == 2); // Alice now has 2 NFTs } ``` ## Recommended Mitigation **Add a claim status check at the beginning of the function** to prevent users from claiming multiple times. ```diff // Add new error + error SA__AlreadyClaimed(); function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s) external nonReentrant { + if (s_hasClaimedSnowman[receiver]) { + revert SA__AlreadyClaimed(); + } + if (receiver == address(0)) { revert SA__ZeroAddress(); } // Rest of function logic... s_hasClaimedSnowman[receiver] = true; } ```
Rewards breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Judging
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsRewards Distribution
The contest is complete and the rewards are being distributed.