Snowman Merkle Airdrop
AI First Flight #10
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Impact: low
Likelihood: medium
Invalid

Snow::buySnow() strict msg.value equality traps overpaid ETH with no refund path

foxcryptie

Root + Impact

Description

  • buySnow() is meant to accept payment either in native ETH (exact price) or in WETH.

  • The branch selection uses strict equality on msg.value: if the attached ETH does not exactly equal s_buyFee * amount, the function falls through to the WETH branch and charges the full price in WETH — but the ETH the caller attached is never refunded or rejected, and simply sits in the contract.

function buySnow(uint256 amount) external payable canFarmSnow {
@> if (msg.value == (s_buyFee * amount)) {
_mint(msg.sender, amount);
} else {
i_weth.safeTransferFrom(msg.sender, address(this), (s_buyFee * amount));
_mint(msg.sender, amount);
}
​
s_earnTimer = block.timestamp;
emit SnowBought(msg.sender, amount);
}

Risk

Likelihood:

  • Occurs whenever a caller sends any ETH alongside a WETH-intended purchase, or slightly over/under the exact ETH price — a realistic UX mistake given there's no buySnowWithETH/buySnowWithWETH split, just one function with an implicit branch.

Impact:

  • The user's overpaid ETH becomes permanently stuck in the Snow contract, with no function anywhere that returns it — it can only ever leave via collectFee(), which sends it to the collector, not back to the payer.

Proof of Concept

The test below buys 1 Snow while attaching price + 1 ether. Since msg.value != price exactly, the WETH branch runs and charges the full price in WETH from the caller's WETH balance — but the 1+ ETH they also attached is never returned, and ends up permanently held by the Snow contract.

function test_H3_buySnow_overpaid_eth_stuck() public {
uint256 price = snow2.s_buyFee();
uint256 overpay = price + 1 ether;
vm.deal(attacker2, overpay);
vm.startPrank(attacker2);
w2.approve(address(snow2), type(uint256).max);
snow2.buySnow{value: overpay}(1); // WETH branch taken, ETH kept too
vm.stopPrank();
​
assertEq(w2.balanceOf(attacker2), 0, "WETH was charged");
assertEq(address(snow2).balance, overpay, "overpaid ETH trapped, no refund");
}
Run: forge test --match-test test_H3_buySnow_overpaid_eth_stuck -vv → PASS, confirming the attached ETH remains in the contract's balance after the WETH-path purchase completes.

Recommended Mitigation

Reject any attached ETH when the WETH path is taken, forcing the caller to pick one payment method explicitly instead of silently losing funds:

function buySnow(uint256 amount) external payable canFarmSnow {
if (msg.value == (s_buyFee * amount)) {
_mint(msg.sender, amount);
} else {
+ if (msg.value != 0) revert S__NotAllowed(); // don't silently accept+strand ETH on the WETH path
i_weth.safeTransferFrom(msg.sender, address(this), (s_buyFee * amount));
_mint(msg.sender, amount);
}
...
}
This makes the two payment paths mutually exclusive: pay exact ETH, or pay in WETH with zero ETH attached — either way, nothing is ever stranded in the contract.
Updates

Lead Judging Commences

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