Root + Impact

A logic bug in claimFaucetTokens() resets the dailyDrips counter via an else { dailyDrips = 0; } block when a caller already received the Sepolia ETH drip (or when drips are paused). This lets an attacker with any previously dripped address repeatedly reset the daily counter and cause the contract to pay out ETH beyond the intended dailySepEthCap.

Description

Inside claimFaucetTokens() the contract attempts to drip Sepolia ETH only to first-time claimants and enforce a daily cap via dailyDrips and lastDripDay. However, an else block unconditionally sets dailyDrips = 0 when the condition (!hasClaimedEth[claimer] && !sepEthDripsPaused) is false - i.e., when the caller has already received ETH or drips are paused.

Because token-only claims by already-dripped addresses execute that else, any such call will reset the daily counter even within the same day. An attacker can:

• Use or create an address A that has already received a Sepolia ETH drip (hasClaimedEth[A] = true).

• After legitimate drips have increased dailyDrips, call claimFaucetTokens() from A (token-only claim), which triggers the else and sets dailyDrips = 0.

• The contract now believes zero ETH has been distributed today and will allow additional first-time claimants to receive ETH up to dailySepEthCap again.

• Repeat to drain ETH repeatedly past the intended daily limit.

Risk

Likelihood:

• The else { dailyDrips = 0; } line resets the daily drip counter in situations where it should not - it is executed when the caller has already claimed ETH. dailyDrips should only be reset on day rollover (i.e., when currentDay > lastDripDay) - not when a caller who previously received ETH calls again.

• Exploitability: Easy - requires only one address that previously received a drip (which is trivial to obtain). No complicated conditions or off-chain coordination needed.

Impact:

• Direct financial impact: High - attacker can bypass dailySepEthCap and drain ETH from the faucet beyond expected limits.

• Severity: High (funds loss/cap bypass).

Proof of Concept

Output:

Recommended Mitigation

• Remove the erroneous else branch so token-only calls won’t zero the counter.