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

Signature Replay Attack due to missing state check allows users to claim multiple NFTs

diegotrigueros

Missing state check in claimSnowman allows Signature Replay and unlimited NFT minting

Description

  • Describe the normal behavior:
    The protocol intends to allow users to claim a Snowman NFT exactly once based on their Snow token holdings, utilizing a Merkle Tree and EIP-712 signatures for verification.

  • Explain the specific issue:
    The claimSnowman function updates the s_hasClaimedSnowman[receiver] mapping to true at the end of execution but fails to check this mapping at the beginning. Additionally, the _isValidSignature check relies solely on the current token balance and the receiver address, without a nonce. This allows a user to claim an NFT (burning tokens), re-acquire the same amount of tokens, and reuse the original signature to claim again indefinitely.

// Root cause in the codebase with @> marks to highlight the relevant section
​
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external
nonReentrant
{
if (receiver == address(0)) {
revert SA__ZeroAddress();
}
// @> BUG: Missing check for s_hasClaimedSnowman[receiver] here
​
if (i_snow.balanceOf(receiver) == 0) {
revert SA__ZeroAmount();
}
// ...

Risk

Likelihood:

  • High: The attack requires no special privileges or complex setup. Any user who has claimed once can simply re-acquire Snow tokens (via earnSnow or buying) and replay their previous transaction data to claim again.

Impact:

  • High: This completely breaks the scarcity of the NFT collection. A single user can mint the entire supply of Snowman NFTs, rendering the airdrop unfair and the economic design broken

Proof of Concept

The following test demonstrates the replay attack. First, Alice performs a legitimate claim using a valid signature. Then, we simulate a time delay where Alice earns Snow tokens again, restoring her balance to the original amount. Finally, a relayer submits the exact same signature used in the first transaction. The test passes successfully, showing that Alice receives a second NFT, proving the contract failed to invalidate the used signature.
​
// Add this to a new test file test/SnowmanReplay.t.sol
​
function testSignatureReplayAllowsDoubleClaim() public {
// 1. Setup: Alice earns 1 Snow token (balance = 1)
vm.prank(alice);
snow.approve(address(airdrop), 100 ether);
​
// 2. Generate valid signature for current state
bytes32 alDigest = airdrop.getMessageHash(alice);
(uint8 v, bytes32 r, bytes32 s) = vm.sign(alKey, alDigest);
​
// 3. First Claim (Legitimate)
vm.prank(satoshi);
airdrop.claimSnowman(alice, AL_PROOF, v, r, s);
assert(nft.balanceOf(alice) == 1);
assert(snow.balanceOf(alice) == 0); // Tokens burned
​
// 4. State Reset: Alice earns 1 Snow token again
vm.warp(block.timestamp + 1 weeks);
vm.prank(alice);
snow.earnSnow();
assert(snow.balanceOf(alice) == 1); // Balance matches original signature condition
​
// 5. REPLAY ATTACK: Using the EXACT same signature and proof
vm.prank(satoshi);
airdrop.claimSnowman(alice, AL_PROOF, v, r, s);
​
// 6. Impact: Alice minted a second NFT
assert(nft.balanceOf(alice) == 2);
}

Recommended Mitigation

The most effective fix is to strictly enforce a "check-effects-interactions" pattern by checking the state variable s_hasClaimedSnowman at the very beginning of the function.
If the user has already claimed, the transaction must revert immediately. Additionally, implementing a nonce in the signature schema would provide defense-in-depth against signature reuse across different states.
​
- remove this code
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external
nonReentrant
{
if (receiver == address(0)) {
revert SA__ZeroAddress();
}
// @> BUG: Missing check for s_hasClaimedSnowman[receiver] here
​
if (i_snow.balanceOf(receiver) == 0) {
revert SA__ZeroAmount();
}
// ...
​
​
+ add this code
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("SnowmanAirdrop: User already claimed");
+ }
if (i_snow.balanceOf(receiver) == 0) {
revert SA__ZeroAmount();
}
// ... rest of the function
Updates

Lead Judging Commences

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