The intended behavior of the s_hasClaimedSnowman mapping and its public getter getClaimStatus is to expose a definitive boolean: true means the address has claimed and cannot claim again, false means the address has not claimed and is still eligible. Any external system (dashboard, governance module, secondary-market verifier, snapshot tool) that reads this getter is entitled to trust that the boolean reflects an enforced claim state.
The specific issue is that s_hasClaimedSnowman[receiver] is written to true at the end of claimSnowman but is NEVER read as a guard inside claimSnowman. Combined with the balance-dependent leaf computation (H-03), this means an address that has already claimed can re-acquire Snow tokens (via earnSnow() or buySnow()) and claim again — the same Merkle proof still verifies, a fresh signature is produced, the mapping write is idempotent (already true), and the claim succeeds. getClaimStatus returns true throughout: once after the first claim, again after the second claim, again after the third. There is no observable difference between a state with N=1 claims and a state with N=2 claims for the same address.
Likelihood:
Reason 1: The re-claim path is exercised by any whitelisted user who calls earnSnow() (free, subject only to a shared global 1-week timer) or buySnow() (paid) after their first claim. Within the 12-week farming window, re-claiming is free and has a 1-week cadence.
Reason 2: The misleading getClaimStatus return value appears in 100% of post-claim states — there is no configuration or edge case in which the getter behaves correctly after a re-claim. Any external system that consumes this getter is affected whenever a re-claim has occurred.
Impact:
Impact 1: External systems that rely on getClaimStatus for business logic — e.g., a governance contract that grants one vote per claimer, a dashboard that reports airdrop completion as claimedCount / totalWhitelisted, a secondary-market listing that requires getClaimStatus == true as proof of claim — receive false data. The reported state diverges silently from the actual on-chain state.
Impact 2: The misalignment between the public interface (which advertises an enforced claim flag) and the internal logic (which does not enforce it) is a trust violation. Users and integrators who read the contract source and see the s_hasClaimedSnowman mapping plus its public getter will reasonably assume the flag is enforced. The trust assumption is broken without any on-chain signal, making the failure mode silent and hard to detect.
Either enforce the flag inside claimSnowman, or remove the misleading getter. The preferred fix is to enforce the flag — this also closes the underlying multi-claim path that depends on the same root cause.
Adding the explicit SA__AlreadyClaimed guard makes the public getter's contract truthful: once getClaimStatus returns true, the address can never claim again. If for any reason the project wants to keep the multi-claim path (e.g., per-round claims), the getter should be removed or renamed to hasAtLeastOneClaim so it cannot be misread as an enforced eligibility flag.
# 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; } ```
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.