Snowman Merkle Airdrop
AI First Flight #10
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Severity: low
Valid

claimSnowman() missing claim replay protection — receiver can claim unlimited Snowman NFTs

squashingbugs007

Root + Impact

Description

  • Normal behavior: claimSnowman() should allow each eligible receiver to claim their Snowman NFT exactly once. The contract sets s_hasClaimedSnowman[receiver] = true after a successful claim.

  • The issue: The s_hasClaimedSnowman mapping is set after each claim but is never checked before processing a new claim. There is no require(!s_hasClaimedSnowman[receiver]) guard anywhere in claimSnowman(). As long as the receiver holds Snow tokens, they can call claimSnowman() repeatedly, draining the Snowman NFT supply and receiving far more NFTs than their Snow token balance warrants.

  • Additionally, Slither flags i_snow.safeTransferFrom(receiver, address(this), amount) as arbitrary-send-erc20 because the from address is a function parameter, if a receiver has approved the contract, an attacker can drain their Snow tokens by supplying the victim's address as receiver.

// Root cause in the codebase with @> marks to highlight the relevant section
​
```solidity
// src/SnowmanAirdrop.sol#69-99
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external nonReentrant
{
// @> s_hasClaimedSnowman is NEVER CHECKED here
if (receiver == address(0)) revert SA__ZeroAddress();
if (i_snow.balanceOf(receiver) == 0) revert SA__ZeroAmount();
// ... signature and merkle verification ...
i_snow.safeTransferFrom(receiver, address(this), amount); // @> arbitrary from
s_hasClaimedSnowman[receiver] = true; // @> set but never read
i_snowman.mintSnowman(receiver, amount);
}
```

Risk

Likelihood:

  • Any eligible receiver can call claimSnowman() multiple times and no guard prevents it.

  • The receiver only needs to re-acquire Snow tokens between claims to repeat the exploit.

Impact:

  • Receiver can claim far more Snowman NFTs than their Snow balance entitles them to.

  • Attacker supplying a victim's address as receiver can drain victim's approved Snow tokens

Proof of Concept

The following Foundry test demonstrates that a receiver can call claimSnowman()
multiple times without restriction. The s_hasClaimedSnowman mapping is set on
line 94 but is never read before processing begins, meaning the check has no
effect. A receiver who re-acquires Snow tokens can repeat the claim indefinitely,
draining the NFT supply.

// Foundry test demonstrating double claim
function testDoubleClaim() public {
// Setup: receiver has Snow tokens and valid proof
vm.startPrank(receiver);
// First claim — legitimate
snowmanAirdrop.claimSnowman(receiver, merkleProof, v, r, s);
uint256 nftsAfterFirst = snowman.balanceOf(receiver);
assertGt(nftsAfterFirst, 0);
// Receiver acquires more Snow tokens
snow.buySnow{value: buyFee * 10}(10);
// Second claim — should revert but DOES NOT
snowmanAirdrop.claimSnowman(receiver, merkleProof, v, r, s);
uint256 nftsAfterSecond = snowman.balanceOf(receiver);
// Receiver now has double the NFTs
assertGt(nftsAfterSecond, nftsAfterFirst);
vm.stopPrank();
}

Recommended Mitigation

The fix requires checking s_hasClaimedSnowman[receiver] at the very start of
claimSnowman(), before any other validation runs. This ensures that once a
receiver has successfully claimed, all future calls revert immediately. The
check must come first, placing it after the balance check would still allow
re-entry if the receiver holds tokens. A new custom error SA__AlreadyClaimed()
is added to maintain the contract's error naming convention.

function claimSnowman(
address receiver,
bytes32[] calldata merkleProof,
uint8 v, bytes32 r, bytes32 s
) external nonReentrant {
+ // @> Check FIRST — before any other validation
+ // s_hasClaimedSnowman was being set but never read
+ if (s_hasClaimedSnowman[receiver]) revert SA__AlreadyClaimed();
if (receiver == address(0)) revert SA__ZeroAddress();
if (i_snow.balanceOf(receiver) == 0) revert SA__ZeroAmount();
// ... signature and merkle verification ...
i_snow.safeTransferFrom(receiver, address(this), amount);
s_hasClaimedSnowman[receiver] = true;
i_snowman.mintSnowman(receiver, amount);
}
​
+ // Also add the missing error definition:
+ error SA__AlreadyClaimed();
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 2 hours ago
Submission Judgement Published
Validated
Assigned finding tags:

[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; } ```

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!