claim() only records two immutable values at deployment (i_airdropToken, i_merkleRoot). It verifies msg.value == FEE and a Merkle proof, then immediately transfers amount tokens to account. There is no mapping/bitmap anywhere in the contract that records whether a given (account, amount) leaf has already been paid out.
A Merkle proof is static, stateless data - MerkleProof.verify(...) will return true for the same valid (account, amount, proof) triple forever. Since nothing marks a leaf as "consumed," the exact same triple can be submitted to claim() an unlimited number of times, each time paying out amount tokens again, as long as the caller is willing to pay the fixed (and effectively negligible) 1e9 wei fee.
claim() also never checks msg.sender == account, so any third party - not just the whitelisted recipient - can trigger a payout for any (account, amount, proof) it has seen. This is sometimes an intentional "anyone can relay/pay gas for you" design, but combined with the missing claimed-tracking above, it turns "one recipient could double-spend their own slot" into "anyone on the network who observes these public parameters (or copies them straight out of another pending claim's calldata in the mempool) can repeatedly drain the whole shared pool before other legitimate recipients ever get to claim."
Likelihood:
Reason 1 // No attacker sophistication is required - a normal EOA calling the public claim() function repeatedly, in order, is sufficient. The only "cost" is repeating a fixed, dust-sized fee (4 replays cost 4 gwei total in our PoC).
Reason 2 // The parameters needed to replay (account, amount, merkleProof) are necessarily public - they must be distributed to users so they can self-serve their claim, and/or they are visible in any pending claim transaction's calldata in the mempool.
Impact:
Impact 1 // The entire shared token pool funded for multiple distinct recipients can be drained by repeatedly claiming a single valid leaf, exactly as the real deployment funds it (Deploy.s.sol sends 4 * 25e6 tokens total for 4 recipients into one shared balance).
Impact 2 // Once drained, every other legitimate whitelisted recipient's claim() call reverts (insufficient contract balance) - a real, quantifiable, permanent loss of funds for everyone except whoever replayed first.
Ran with forge test --match-path "test/PoC_0.t.sol" -vv: both [PASS] testReplayDrainsEntirePoolAndLocksOutOtherLegitimateClaimants() and [PASS] testThirdPartyCanTriggerRepeatedPayoutsWithoutBeingTheAccount(). The protocol funds the pool exactly as the real Deploy.s.sol would (100 tokens total, meant for 4 recipients of 25 each). An attacker with no special privileges replays the same valid (account, amount, proof) triple 4 times, draining the entire 100-token pool to a single address; a subsequent claim attempt for the same leaf then reverts because the contract balance is exhausted. A second test isolates the msg.sender != account gap: a completely unrelated third party pays the fee twice and collects zero tokens for itself, while the whitelisted leaf owner passively receives double its intended allocation - proving the claim count per leaf is fully unbounded and attacker-controlled.
Track claimed leaves (e.g. a mapping(bytes32 => bool), or a bitmap indexed by leaf position for gas savings, following the pattern used by Uniswap's MerkleDistributor) and mark the leaf as claimed before the external safeTransfer call, respecting checks-effects-interactions. Separately consider whether msg.sender == account should be enforced, depending on whether third-party-relayed claims are an intended feature.
## Description A user eligible for the airdrop can verify themselves as being part of the merkle tree and claim their airdrop amount. However, there is no mechanism enabled to track the users who have already claimed their airdrop, and the merkle tree is still composed of the same user. This allows users to drain the `MerkleAirdrop` contract by calling the `MerkleAirdrop::claim()` function over and over again. ## Impact **Severity: High**<br/>**Likelihood: High** A malicious user can call the `MerkleAirdrop::claim()` function over and over again until the contract is drained of all its funds. This also means that other users won't be able to claim their airdrop amounts. ## Proof of Code Add the following test to `./test/MerkleAirdrop.t.sol`, ```javascript function testClaimAirdropOverAndOverAgain() public { vm.deal(collectorOne, airdrop.getFee() * 4); for (uint8 i = 0; i < 4; i++) { vm.prank(collectorOne); airdrop.claim{ value: airdrop.getFee() }(collectorOne, amountToCollect, proof); } assertEq(token.balanceOf(collectorOne), 100e6); } ``` The test passes, and the malicious user has drained the contract of all its funds. ## Recommended Mitigation Use a mapping to store the addresses that have claimed their airdrop amounts. Check and update this mapping each time a user tries to claim their airdrop amount. ```diff contract MerkleAirdrop is Ownable { using SafeERC20 for IERC20; error MerkleAirdrop__InvalidFeeAmount(); error MerkleAirdrop__InvalidProof(); error MerkleAirdrop__TransferFailed(); + error MerkleAirdrop__AlreadyClaimed(); uint256 private constant FEE = 1e9; IERC20 private immutable i_airdropToken; bytes32 private immutable i_merkleRoot; + mapping(address user => bool claimed) private s_hasClaimed; ... function claim(address account, uint256 amount, bytes32[] calldata merkleProof) external payable { + if (s_hasClaimed[account]) revert MerkleAirdrop__AlreadyClaimed(); if (msg.value != FEE) { revert MerkleAirdrop__InvalidFeeAmount(); } bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(account, amount)))); if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) { revert MerkleAirdrop__InvalidProof(); } + s_hasClaimed[account] = true; emit Claimed(account, amount); i_airdropToken.safeTransfer(account, amount); } ``` Now, let's unit test the changes, ```javascript function testCannotClaimAirdropMoreThanOnceAnymore() public { vm.deal(collectorOne, airdrop.getFee() * 2); vm.prank(collectorOne); airdrop.claim{ value: airdrop.getFee() }(collectorOne, amountToCollect, proof); vm.prank(collectorOne); airdrop.claim{ value: airdrop.getFee() }(collectorOne, amountToCollect, proof); } ``` The test correctly fails, with the following logs, ```shell Failing tests: Encountered 1 failing test in test/MerkleAirdropTest.t.sol:MerkleAirdropTest [FAIL. Reason: MerkleAirdrop__AlreadyClaimed()] testCannotClaimAirdropMoreThanOnceAnymore() (gas: 96751) ```
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.