Snowman Merkle Airdrop

Description

Snowman.mintSnowman(address,uint256) is the only mint path for the airdrop NFT and it has no access control at all, even though the contract declares an error that exists precisely to forbid this:

// src/Snowman.sol L20 — declared, referenced nowhere else in the repo
error SM__NotAllowed();

// L36–L44 — external, no modifier, loop bound supplied by the caller, no maximum
function mintSnowman(address receiver, uint256 amount) external {
    for (uint256 i = 0; i < amount; i++) {
        _safeMint(receiver, s_TokenCounter);
        emit SnowmanMinted(receiver, s_TokenCounter);
        s_TokenCounter++;
    }
}

The unused SM__NotAllowed() is the strongest evidence that an onlyAirdrop-style guard was intended and never written: there is no owner in Snowman.sol, no minter registry, no onlyOwner, nothing that records which contract is allowed to mint. Any externally-owned account can call it directly.

The second half of the problem is the loop bound. amount is used directly as the iteration count with no upper limit, and on the airdrop path that number is chosen by the claimer's own token balance:

// src/SnowmanAirdrop.sol L84 → L98
uint256 amount = i_snow.balanceOf(receiver);   // the claimer controls this through Snow.buySnow(amount)
...
i_snowman.mintSnowman(receiver, amount);       // one _safeMint + one event per unit of balance

Snow.buySnow(uint256 amount) accepts an arbitrary amount (src/Snow.sol L79), so a user can accumulate a large Snow balance and then submit a claim whose transaction performs that many _safeMint calls plus that many emit statements. Gas grows linearly with the caller's balance and there is no guard, chunking or per-leaf cap anywhere between claimSnowman and _safeMint.

Risk

• The collection's supply is public property. Anyone can mint any quantity to any address outside every Merkle allocation (nft.mintSnowman(random, 1000) succeeds), so getTokenCounter() and the holders' shares are determined by whoever calls the function, not by the sponsor's distribution table. Combined with my other finding (the claim path is replayable) there is no upper bound on Snowman supply from either direction.

• Large claims cannot complete. A claim mints one NFT per unit of the claimer's balance; once that number exceeds what fits in a block, claimSnowman reverts for the very users who accumulated the most Snow — they can never redeem, and each attempt costs them gas. This is a denial-of-service on the claim path that scales with user activity rather than with an attacker's effort.

• Claim cost is unpredictable. Because the loop count comes from a balance anyone can change at will, a front-end cannot quote or bound the gas of a claim transaction.

Impact is medium (the NFT collection's scarcity and the usability of the claim path are both affected; no funds are drained directly) and likelihood is high: the unrestricted mint needs only one ordinary external call by any address, and a large-balance claim is a normal user state in this protocol.

Proof of Concept

Overview: mintSnowman is unauthenticated and its loop bound is caller-supplied, so (a) any address can mint arbitrary quantities outside the Merkle distribution and (b) a claim whose amount comes from a large balance cannot complete.

Actors — Attacker: any address (not the owner; Snowman has no owner; not SnowmanAirdrop). Victim: existing Snowman holders/collectors (diluted supply, meaningless token counter) and large-balance claimers whose claim transaction cannot fit in a block. Protocol: Snowman mint path, reached from SnowmanAirdrop.claimSnowman L98 with amount = balanceOf(receiver) (L84).

test/FindingSnowmanAirdrop.t.sol::test_F6_mintSnowman_is_unrestricted_and_loop_is_unbounded

function test_F6_mintSnowman_is_unrestricted_and_loop_is_unbounded() public {
    address random = makeAddr("random");            // a plain address: not the airdrop contract, and Snowman has no owner
    uint256 tokenCountBefore = nft.getTokenCounter();

    // (a) anyone can mint an arbitrary quantity directly, outside every Merkle allocation
    nft.mintSnowman(random, 1000);
    assertEq(nft.balanceOf(random), 1000);          // 1000 NFTs that no leaf ever allocated
    assertEq(nft.getTokenCounter(), tokenCountBefore + 1000); // the collection counter moved with an arbitrary caller

    // (b) the loop bound is the caller's number: a huge amount cannot complete.
    //     On the claim path this same number is balanceOf(receiver) (SnowmanAirdrop L84 -> L98).
    vm.expectRevert();                              // out of gas / above block gas limit
    nft.mintSnowman(random, 5_000_000);
}

$ forge test --match-test test_F6_mintSnowman_is_unrestricted_and_loop_is_unbounded -vv
[PASS] test_F6_mintSnowman_is_unrestricted_and_loop_is_unbounded() (gas: 33224733)
Suite result: ok. 1 passed; 0 failed

The first two assertions prove the missing access control (a random address minted 1000 tokens and moved the collection counter); the vm.expectRevert() proves the unbounded loop is not completable at a large amount. The measured 33.2M gas for 1000 mints shows the linear cost directly: ~33k gas per unit, so a claim backed by a balance in the tens of thousands is already past what a normal transaction can carry — and it reverts at SnowmanAirdrop L98.