Root + Impact

Description

• The `claim` function accepts an `account` parameter that can be different from `msg.sender`, allowing anyone to claim airdrops on behalf of other users if they possess the merkle proof. While the tokens still go to the correct recipient, this creates trust issues and could be exploited if combined with double-claim prevention.

  ### Root + Impact

  The function doesn't verify that `msg.sender == account`, allowing third parties to initiate claims for others.

  ```solidity

  // src/MerkleAirdrop.sol:30

  function claim(address account, uint256 amount, bytes32[] calldata merkleProof) external payable {

  ```

  If a merkle proof is leaked or shared, anyone can call `claim()` on behalf of the eligible user. While the tokens go to the correct `account`, this creates several issues:

  - The caller pays the fee but doesn't receive tokens

  - If double-claim prevention is added, a malicious actor could claim for a user before they do, blocking the legitimate user

  - Creates unnecessary trust requirements around proof distribution

Risk

Likelihood:

• * Merkle proofs may be shared or leaked during distribution

  * Anyone with access to a proof can call the function with that account's address

  * No validation prevents this behavior

  * This occurs whenever proofs are not kept private

Impact:

• * Users may have their claims initiated by third parties without consent

  * If double-claim prevention exists, users could be permanently blocked from claiming

  * Creates confusion about who can claim and when

  * Potential for griefing attacks where attackers claim for users to waste their own gas

Proof of Concept

Recommended Mitigation