Each receiver in the merkle tree is intended to claim their Snowman NFTs exactly once. The contract declares a s_hasClaimedSnowman mapping and writes to it after a successful claim, but the
claimSnowman function never reads it. The only barriers against a repeat claim are the receiver's Snow balance being non-zero and the merkle proof matching the on-chain leaf — both of which an
attacker can re-satisfy.
The merkle leaf is recomputed at claim time using amount = i_snow.balanceOf(receiver). After a claim, the receiver's Snow balance is transferred to the airdrop contract via safeTransferFrom,
bringing balance to 0. If the receiver re-acquires Snow tokens (via transfer from another wallet, secondary market, or another earn cycle) and brings their balance back to the exact value listed in the
merkle tree, the proof verifies and the claim succeeds again, minting a new batch of Snowman NFTs.
Likelihood:
After a legitimate claim the receiver's balance is 0; the receiver only needs another wallet to transfer the same amount of Snow back. Snow is an openly transferable ERC20 with no whitelist.
Snow tokens can also be earned via earnSnow() or bought via buySnow() until FARMING_DURATION expires, making balance replenishment cheap and permissionless during the farming window.
Impact:
A single receiver can mint N rounds of Snowman NFTs (one per replenishment cycle) instead of the intended one, diluting the NFT supply and stealing supply from other legitimate claimants.
The signature (v, r, s) is reusable because the digest has no nonce; the same signature applies as long as the balance equals the tree amount.
The following test demonstrates the double-claim vector. Alice is a legitimate airdrop recipient with a balance of exactly 10 Snow at tree generation. She claims successfully and her balance is drained
to 0. Bob then transfers 10 Snow back to Alice, restoring her balance to the exact merkle-tree value. Because s_hasClaimedSnowman[alice] is never checked, Alice re-claims with the same signature and
merkle proof, doubling her Snowman holdings.
The exploit cycle can be repeated indefinitely: each cycle requires only that the receiver re-acquire amount Snow tokens. The cost per cycle is one transfer's gas plus the time to acquire/borrow Snow.
Read the s_hasClaimedSnowman mapping at the top of claimSnowman and revert with a dedicated error if the receiver has already claimed. The mapping is already being written; we are only adding the
read side of the check. This restores single-claim semantics without changing the merkle/signature flow.
With this guard in place, any re-claim attempt after the first successful claim reverts at the new check, regardless of subsequent balance replenishment or signature reuse.
# 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.