Raisebox Faucet
First Flight #50
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Impact: medium
Likelihood: medium
Invalid

M02. Risk of front-running

accessdenied

Root + Impact

Description

  • The RaiseBoxFaucet contract is designed to distribute faucet tokens and Sepolia ETH to users, with daily limits and per-address tracking to prevent abuse.

  • The contract does not enforce limits per attacker-controlled addresses, allowing a single actor to create multiple accounts and claim ETH repeatedly. This enables a Sybil-style attack that can drain the faucet quickly.

// Root cause in the codebase with @> marks to highlight the relevant section
if (!hasClaimedEth[faucetClaimer] && !sepEthDripsPaused) {
> // Only checks per-address and not per-actor, allowing multiple addresses to claim ETH
}
​

Risk

Likelihood:

  • Attackers can deploy or control multiple addresses to repeatedly call claimFaucetTokens() and bypass intended distribution limits.

  • High-speed or automated interactions can maximize faucet draining, especially on testnets with low-value ETH.

Impact:

  • Sepolia ETH balance in the faucet can be rapidly drained, leaving legitimate users without access.

  • Distribution fairness is broken, as a single actor can claim far more than intended.

Proof of Concept

1. Deploy multiple externally owned accounts or smart contracts controlled by a single actor.
2. Each address calls `claimFaucetTokens()` in sequence or via automated scripts.
3. Observe that each new address can claim ETH despite the intended per-day caps for individual users.
4. Monitor faucet contract balance dropping quickly while legitimate users cannot claim.
​

Explanation: The faucet only tracks ETH claims per individual address. Since the contract does not link addresses to a single actor or enforce stricter identity checks, attackers can create multiple addresses to repeatedly drain ETH.

Recommended Mitigation

\

- no limit per actor, only per address
+ implement anti-Sybil measures such as CAPTCHA, token gating, or limiting claims per transaction origin
Updates

Lead Judging Commences

inallhonesty Lead Judge 5 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

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