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

[M-01] Missing `s_hasClaimedSnowman` check enables claim replay if receiver re-acquires equal Snow balance

cthan

[M-01] Missing s_hasClaimedSnowman check enables claim replay if receiver re-acquires equal Snow balance

Description

SnowmanAirdrop declares an explicit replay-protection mapping but never reads it inside the claim path:

// src/SnowmanAirdrop.sol:47
mapping(address => bool) private s_hasClaimedSnowman;
​
// src/SnowmanAirdrop.sol:94 (inside claimSnowman) — flag is SET
s_hasClaimedSnowman[receiver] = true;
​
// The flag is read only in src/SnowmanAirdrop.sol:138 (external view getClaimStatus),
// which gates nothing — it is exposed for off-chain consumers only.

The only de facto replay guard is the balance check at line 76:

if (i_snow.balanceOf(receiver) == 0) {
revert SA__ZeroAmount();
}

After a successful claim, claimSnowman transfers all of receiver's Snow to the airdrop contract (line 92), so a second claim attempt reverts at this check. However, this guard is contingent, not designed: if the receiver re-acquires Snow tokens equal to their original Merkle-tree eligibility, every check in claimSnowman re-passes:

  • balanceOf(receiver) != 0 ✓

  • getMessageHash(receiver) reads current balance (= original eligibility) → digest matches the OLD signature ✓

  • Merkle.verify against the same (receiver, amount) leaf ✓

  • Snow transferred again, NFTs minted again

The s_hasClaimedSnowman[receiver] flag is set but never gates the second call.

Risk

  • Likelihood: Medium — today, gated by H-02 (the decimals bug makes re-acquiring meaningful Snow balances economically infeasible). After H-02 is fixed, gating drops to "buy Snow at fair price and replay" — likelihood becomes High.

  • Impact: High — receivers can mint NFTs beyond their Merkle-tree eligibility, breaking protocol fairness and inflating Snowman NFT supply beyond the intended cap.

  • Risk = Likelihood × Impact = Medium (today; would be High post-H-02-fix)

Impact

A receiver eligible for N NFTs can claim 2N, 3N, ..., kN NFTs by repeatedly re-acquiring Snow and replaying their original (merkleProof, v, r, s). Today this is mitigated by H-02's broken economics (re-acquiring 1000 Snow requires 10^18 ETH). After H-02 is fixed, the replay vector is straightforward: a receiver eligible for 1000 NFTs can pay roughly 1000 ETH worth of Snow per replay round and walk away with 1000 additional NFTs each round — profitable as long as NFT floor price exceeds Snow cost basis, which is the entire premise of an airdrop incentive. NFT supply inflates beyond design caps; airdrop fairness is destroyed.

Proof of Concept

Full PoC at .audit/poc/PoC_M-01.t.sol. The key test function uses deal() to bypass H-02's economic friction and isolate the M-01 replay bug:

function test_ReplayClaim_DoublesNftMint() public {
// PHASE 1: fund receiver with eligible balance and sign
deal(address(snow), receiver, AMOUNT);
vm.prank(receiver);
snow.approve(address(airdrop), type(uint256).max);
​
bytes32 digest = airdrop.getMessageHash(receiver);
(uint8 v, bytes32 r, bytes32 s) = vm.sign(receiverKey, digest);
​
// PHASE 2: FIRST CLAIM (legitimate)
airdrop.claimSnowman(receiver, emptyProof, v, r, s);
assertEq(snowman.balanceOf(receiver), AMOUNT, "first claim mints AMOUNT NFTs");
assertEq(snow.balanceOf(receiver), 0, "Snow consumed by first claim");
assertTrue(airdrop.getClaimStatus(receiver), "s_hasClaimedSnowman set, but never read");
​
// PHASE 3: receiver re-acquires the same Snow balance (post-H-02-fix scenario)
deal(address(snow), receiver, AMOUNT);
​
// PHASE 4: REPLAY with identical (proof, v, r, s) — every check re-passes
airdrop.claimSnowman(receiver, emptyProof, v, r, s);
​
// KEY ASSERTION: receiver now holds 2x their Merkle eligibility in NFTs
assertEq(snowman.balanceOf(receiver), 2 * AMOUNT, "replay: 2x eligibility minted");
}

Test passes inside hardened audit container (forge exit 0). Receiver eligible for 3 NFTs walks away with 6 — the same (proof, v, r, s) accepted twice because s_hasClaimedSnowman is never read.

Recommended Mitigation

Add the missing claim-flag check at the start of claimSnowman so the replay guard is explicit and not contingent on Snow's economic state:

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]) { // ← NEW: explicit replay guard
revert SA__AlreadyClaimed();
}
if (i_snow.balanceOf(receiver) == 0) {
revert SA__ZeroAmount();
}
// ... rest unchanged
}

This makes the replay guard explicit and designed, working regardless of whether H-02 is fixed or what Snow's economics look like.

Updates

Lead Judging Commences

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