🎁 The Rewarder - Merkle Proof Hijacking

Challenge Overview

TheRewarderDistributor uses Merkle Trees to distribute rewards in multiple tokens such as DVT and WETH. The contract uses a bitmap to prevent double claims and supports batch claiming for gas efficiency.

Goal: Drain all unclaimed rewards from the distributor and send them to the recovery account.

Technical Analysis

The Vulnerable Code

The vulnerability exists inside the claimRewards function.

1
// Merkle leaf used for verification
2
bytes32 leaf = keccak256(
3
    abi.encodePacked(
4
        inputClaim.batchNumber,
5
        inputClaim.amount,
6
        inputClaim.tokenIndex
7
    )
8
);
9

10
// Verify Merkle proof
11
if (!MerkleProof.verify(inputClaim.proof, root, leaf)) {
12
    revert InvalidProof();
13
}
14

15
// Transfer rewards to caller
16
inputTokens[inputClaim.tokenIndex].transfer(
17
    msg.sender,
18
    inputClaim.amount
19
);

Root Cause: Missing Recipient Binding

The contract verifies only:

• batchNumber
• amount
• tokenIndex

But it completely ignores the actual reward recipient.

This means the Merkle proof only proves:

“Someone can claim this amount.”

It does not prove:

“This specific user is the rightful owner of the reward.”

Because the recipient address is not included in the Merkle leaf, anyone can reuse another user’s valid proof and redirect the rewards to themselves.

Why This Is Dangerous

A secure Merkle distributor should include the beneficiary address inside the leaf:

1
keccak256(
2
    abi.encodePacked(
3
        beneficiary,
4
        batchNumber,
5
        amount,
6
        tokenIndex
7
    )
8
);

And the contract should also verify:

1
require(beneficiary == msg.sender);

Without this binding, proofs become transferable.

Merkle proofs are public data and are usually exposed through:

• frontend JSON files
• APIs
• event logs
• snapshots

An attacker can simply collect valid proofs and reuse them to steal every unclaimed reward.

The Exploit

Attack Steps

1. Collect publicly available Merkle proofs.

2. Extract valid:

   • batch numbers
   • amounts
   • token indexes
   • proofs

3. Call claimRewards.

4. Since the contract transfers tokens directly to msg.sender, the attacker receives all rewards.

Exploit Example

1
claims[0] = Claim({
2
    batchNumber: 0,
3
    amount: 115 ether,
4
    tokenIndex: 0,
5
    proof: dvtProof
6
});
7

8
claims[1] = Claim({
9
    batchNumber: 0,
10
    amount: 1 ether,
11
    tokenIndex: 1,
12
    proof: wethProof
13
});
14

15
distributor.claimRewards(claims, tokensToClaim);

The proof remains valid because the recipient address is never verified.

Impact

An attacker can:

• steal every unclaimed reward
• drain the entire distributor contract
• bypass the intended whitelist system

This vulnerability completely breaks the security model of the Merkle distributor.

Remediation

Always bind the Merkle proof to the intended recipient.

Secure Leaf Construction

1
bytes32 leaf = keccak256(
2
    abi.encodePacked(
3
        beneficiary,
4
        batchNumber,
5
        amount,
6
        tokenIndex
7
    )
8
);

Verify Ownership

1
require(beneficiary == msg.sender, "Not reward owner");

This ensures proofs cannot be reused by arbitrary users.

Key Takeaways

• Merkle proofs must include user identity.
• Public proofs are not secrets.
• Never transfer assets to msg.sender unless ownership is verified.
• Missing recipient binding turns Merkle distributions into public withdrawals.