The faucet intends to limit who can call claimFaucetTokens(). The revert name RaiseBoxFaucet_OwnerOrZeroOrContractAddressCannotCallClaim implies that contract callers should be blocked, allowing only EOAs (regular users) to claim.
The actual check does not verify whether msg.sender is a contract. It only rejects the zero address, the faucet itself, and the owner. As a result, any arbitrary contract can call and automate claims, including reentrant or farming contracts.
Likelihood: High
Whenever a bot or smart contract calls claimFaucetTokens(), the function does not detect it as a contract and allows the call to proceed.
Operationally, this will occur routinely in adversarial environments where users deploy simple helpers to automate or scale faucet interactions.
Impact: Medium
Automated farming: Scripts and on-chain bots can coordinate repeated claims (across many contracts), reducing fairness and exhausting faucet resources faster than intended.
Automated farming: Scripts and on-chain bots can coordinate repeated claims (across many contracts), reducing fairness and exhausting faucet resources faster than intended.
This is my POC from another report, which demonstrates the reentrancy attack (therefore, call from another contract is possible)
In the test directory create file PocReent.t.sol
Copy bellow code and run forge test --match-path PocReent
If contracts should be allowed:
Rename the error to something accurate (e.g., OwnerOrZeroOrSelfCannotClaim) and remove misleading comments.
If contracts should be blocked (EOA-only, with caveats):
Add an explicit code-size or tx.origin check (note: these approaches block multisigs, smart wallets, and can be bypassed in some advanced patterns).
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.
The contest is complete and the rewards are being distributed.