AirDropper
AI First Flight #5
Beginner FriendlyDeFiFoundry
EXP
View results
Previous Next
Submission Details
Impact: high
Likelihood: high
Invalid

zkSync native AA breaks msg.sender assumption in claim allowing unauthorized claims

0xjjjjjj

Summary

On zkSync Era with native account abstraction, msg.sender in claim() can differ from the eligible account, but the function has no mechanism to verify authorization between the two.

Vulnerability Details

In MerkleAirdrop.sol:30, claim accepts account as a parameter with no check that msg.sender == account:

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

zkSync natively supports account abstraction — smart contract wallets are first-class citizens. msg.sender is the contract wallet, not the EOA. Since account and msg.sender are decoupled with no signature check, any address can trigger claims for any eligible account.

Impact

HIGH — The claim function assumes msg.sender == account (EOA model), but zkSync's native AA breaks this. Unauthorized parties can trigger claims.

Proof of Concept

function testAAMismatch() public {
address aaWallet = makeAddr("aaWallet");
vm.deal(aaWallet, 1 ether);
vm.prank(aaWallet);
airdrop.claim{value: 1e9}(collectorOne, amountToCollect, proof);
assertEq(token.balanceOf(collectorOne), amountToCollect);
}

Recommended Fix

Require EIP-712 signature from account to authorize the claim.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 19 hours ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

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

Give us feedback!