The claim flag s_hasClaimedSnowman is written but never read, so one eligible address can claim its allocation an unlimited number of times

Description

• A Merkle airdrop distributes a fixed allocation once per listed address. SnowmanAirdrop is built to enforce that: it declares mapping(address => bool) private s_hasClaimedSnowman, describes it in a comment as the mapping "to verify if an address has claimed Snowman", sets it during claimSnowman, and exposes it through the public getter getClaimStatus.

• The flag is never read anywhere in the claim path. claimSnowman contains no check against s_hasClaimedSnowman before minting, so the write at the end of the function records history that nothing consults. The only other reference in the contract is the external getter. The signature is also replayable: the digest covers only (receiver, amount) with no nonce and no deadline, so a single signature authorises every future claim at that amount.

Grepping the contract for the mapping returns exactly three occurrences: the declaration, this write, and the getter. There is no fourth.

The reason this is not self-limiting is that Snow can be reacquired for free. claimSnowman transfers the claimant's balance into the airdrop contract, which drops the balance to zero and would otherwise stop a second claim at the SA__ZeroAmount check. But Snow::earnSnow mints one base unit to any caller for free, and every recipient in the project's own script/flakes/input.json is listed with an amount of exactly 1. So a claimant returns to precisely the balance their leaf commits to, and the same proof and the same signature verify again.

Risk

Likelihood:

• The claimant needs no attacker, no special privilege, and no cooperation from anyone. They reuse the signature and proof they already produced for their legitimate first claim.

• earnSnow restores the required balance for free, and the allocation amounts in the project's own input file are exactly 1, the value earnSnow mints. The reacquisition step therefore lands on the required balance exactly, with no calculation and no cost beyond gas.

• Every listed recipient can do this, and the profit is strictly positive, so a rational recipient does it.

Impact:

• The airdrop mints unbounded NFTs against a fixed allocation. The invariant that a listed address receives its committed amount and no more does not hold.

• The Snowman supply is inflated without limit over time, diluting every honestly claimed NFT.

• getClaimStatus reports true for an address that is still claiming, so any off-chain accounting, dashboard or downstream integration that trusts this getter is reporting a state the contract does not enforce.

Proof of Concept

Deployment and Merkle proofs are the project's own, taken from script/Helper.s.sol and test/TestSnowmanAirdrop.t.sol. Alice signs once. The signature and proof are captured before the first claim and reused unmodified for all four subsequent claims.

Result:

Five NFTs against a one-NFT allocation, with getClaimStatus returning true throughout. The loop count of four is arbitrary; the bound is how many times the claimant is willing to reacquire Snow, and earnSnow is free.

Scope note. The reacquisition is rate limited in practice, because Snow::earnSnow is gated on a timer. That limits the rate of the extra mints, not the total: the loop has no terminating condition and the allocation is exceeded permanently after the second claim. The finding is the missing guard, not the throughput.

Recommended Mitigation

Read the flag that the contract already maintains, before doing any work. A dedicated error makes the failure legible.

and set the flag before the external calls rather than between them, so the guard holds under the checks-effects-interactions ordering rather than relying on the nonReentrant modifier alone:

Separately, the signature should carry a per-receiver nonce so that one authorisation cannot be replayed even if the claim guard is later relaxed or the contract is reused for a second airdrop round.

Distinctness

This is a separate defect from the unrestricted Snowman::mintSnowman mint and from the leaf being rebuilt from the live balance, and each has an independent fix:

• The unrestricted mint lives in Snowman.sol and is fixed by adding access control there. Fixing it does not add a claim guard to SnowmanAirdrop, so repeat claiming through the legitimate path would still work.

• The live-balance leaf causes claims to fail; this causes claims to succeed too often. They are opposite failures of the same function and are fixed by different changes: one by taking the amount as a parameter, this one by reading the flag.