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

Missing Claim State Tracking in MerkleAirdrop Allows Eligible Users to Drain the Entire Token Pool via Replay Attacks

aliamvaliama1b2

Root + Impact

Description

  • Describe the normal behavior in one or more sentences

  • Explain the specific issue or problem in one or more sentences

### Description
The `MerkleAirdrop` contract allows users to claim airdropped tokens by providing a valid Merkle proof. However, the contract completely lacks any state tracking mechanism to record whether an address or a specific leaf in the Merkle tree has already claimed their allocation.
​
### Root Cause
Inside the `claim` function (lines 30-40), the contract verifies the Merkle proof using:
`if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) { revert MerkleAirdrop__InvalidProof(); }`
​
If the proof is valid, it directly triggers the token transfer:
`i_airdropToken.safeTransfer(account, amount);`
​
The critical flaw is that there is no mapping (e.g., `mapping(address => bool) public hasClaimed`) updated or checked during execution. A leaf remains valid indefinitely.
​
### Impact
This creates a critical vulnerability. Any eligible user in the Merkle tree can call the `claim` function repeatedly in a loop. By paying the nominal `FEE` on each iteration, the attacker can execute a replay attack to drain the entire token balance of the contract (`i_airdropToken`) within minutes.
​
### Proof of Concept (PoC)
1. An attacker with a valid allocation of 100 tokens invokes `claim()` with their correct proof and amount.
2. The contract verifies the proof, passes the check, and transfers 100 tokens to the attacker.
3. Because no state variable is toggled to mark the allocation as "spent", the attacker calls `claim()` again with the exact same arguments and proof.
4. The transaction succeeds again, and another 100 tokens are transferred.
5. The attacker repeats this until the contract's total token pool is completely drained.
​
### Tools Used
Manual Analysis / VS Code
​
### Recommended Mitigation
Introduce a mapping to track the claim status of each address or leaf index, and enforce a check at the beginning of the `claim` function:
​
```solidity
mapping(address => bool) public s_hasClaimed;
​
// Inside claim():
if (s_hasClaimed[account]) { revert MerkleAirdrop__AlreadyClaimed(); }
s_hasClaimed[account] = true;
```
​

Risk

Likelihood:

  • Reason 1 // Describe WHEN this will occur (avoid using "if" statements)

  • Reason 2

Impact:

  • Impact 1

  • Impact 2

Proof of Concept

​

Recommended Mitigation

- remove this code
+ add this code
Updates

Lead Judging Commences

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