SNARKeling Treasure Hunt
First Flight #59
Beginner FriendlyGameFiFoundry
100 EXP
View all submissions
Previous Next
Submission Details
Impact: low
Likelihood: low

Asymmetric Recipient Validation Pattern

Author Revealed upon completion

Root + Impact

Description

  • The validation logic for recipient addresses is asymmetric between claim() and emergencyWithdraw(). While claim() properly validates against address(0), address(this), owner, and msg.sender, the emergencyWithdraw() validation uses a different subset (missing msg.sender check), creating inconsistent validation patterns across functions.

// file: TreasureHunt.sol
**claim() validation (L86)**:
```solidity
if (recipient == address(0) || recipient == address(this) || recipient == owner || recipient == msg.sender)
revert InvalidRecipient();
```
​
**emergencyWithdraw() validation (L276)**:
```solidity
require(recipient != address(0) && recipient != address(this) && recipient != owner, "INVALID_RECIPIENT");
```

Risk

Likelihood:

  • Reason 1

Impact:

  • Inconsistent security model across different flows

  • Potential bypass of validation assumptions

  • Code maintainability issue

Proof of Concept

​

Recommended Mitigation

Standardize recipient validation across all functions, using a shared internal validation function.

​

Support

FAQs

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

Give us feedback!