Snowman Merkle Airdrop

AI First Flight #10
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Submission Details
Impact: low
Likelihood: low
Invalid

[Informational] Missing Zero Address Validation in Owner Functions - Snowman.sol

Summary

During Hour 6 of Snowman First Flight, I reviewed input validation in Snowman.sol. Found that mint() and setOwner() do not validate for zero address. While not directly exploitable, sending tokens to address(0) burns them and transferring ownership to address(0) can brick the contract.

Vulnerability Details

Severity: Low - Informational
Contract: Snowman.sol
Functions: mint(address,uint256), setOwner(address)

Risk

  1. Owner can accidentally call mint(0x0, 1000) and tokens are permanently burned

  2. Owner can accidentally call setOwner(0x0) and lose control of the contract forever

  3. No direct attacker vector, but human error risk exists
    Does not cause immediate loss but is a footgun.

Description

OpenZeppelin best practices require validating that address parameters are not address(0). The current functions trust the owner to input correct addresses. Adding a simple require check prevents accidental loss of tokens or ownership.

Proof of Concept

// Current risky code
function mint(address to, uint256 amount) external onlyOwner {
_mint(to, amount); // If to == address(0), tokens are burned
}
function setOwner(address newOwner) external onlyOwner {
owner = newOwner; // If newOwner == address(0), contract is bricked
}
// Attack: Not an attack. Just a fat-finger mistake:
// owner calls mint(0x0000000000000000000000000000000000000000, 1000000)
error ZeroAddress();
function mint(address to, uint256 amount) external onlyOwner {
if (to == address(0)) revert ZeroAddress();
_mint(to, amount);
}
function setOwner(address newOwner) external onlyOwner {
if (newOwner == address(0)) revert ZeroAddress();
owner = newOwner;
}
## Summary
During my security review of Snowman.sol, I analyzed the input validation logic. I found that critical functions do not validate for zero address inputs. This creates a risk of accidental token burns and loss of contract ownership. No exploit was found, but this is a preventative security measure.
## Vulnerability Details
**Severity:** Low - Informational
**Contract:** Snowman.sol
**Functions Affected:** mint(address,uint256), setOwner(address)
## Risk
1. If owner accidentally calls mint(address(0), amount), tokens are permanently burned
2. If owner accidentally calls setOwner(address(0)), contract becomes unmanageable forever
3. Impacts contract safety and user funds through human error
No direct attacker can exploit this, but it is a serious footgun.
## Description
Following OpenZeppelin best practices, all functions that accept an address parameter should validate against address(0). The current implementation assumes the owner will never make a mistake. Adding a simple require/if check prevents accidental loss of assets and control. This is standard across all major DeFi protocols.
## Proof of Concept
```solidity
// Vulnerable code
function mint(address to, uint256 amount) external onlyOwner {
_mint(to, amount); // No check for to == address(0)
}
function setOwner(address newOwner) external onlyOwner {
owner = newOwner; // No check for newOwner == address(0)
}
// Scenario: Owner fat-fingers the address
// Result: 1,000,000 tokens burned or contract ownership lost forever
Updates

Lead Judging Commences

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