The contract exposes fund() with owner-only access checks, which implies a controlled funding path.
The issue is that receive() accepts ETH from any sender without access control. This bypasses the owner-only funding rule and creates inconsistent behavior between two funding entry points.
Likelihood:
Any address can transfer ETH directly to contract.
Existing test confirms non-owner funding via receive() succeeds.
Impact:
Access-control model for funding becomes inconsistent.
Off-chain accounting and operational assumptions about trusted funding source can be incorrect.
Written reproduction flow:
Keep owner-only fund() policy unchanged.
Send ETH directly from non-owner to contract address.
Observe transfer succeeds and Funded emits.
Use either function receive() or function fund() consistently with one policy.
Or remove owner restriction from fund() and document permissionless funding explicitly.
Although the explicit `fund()` function is restricted to the owner via `require(msg.sender == owner, "ONLY_OWNER_CAN_FUND")`, the contract also implements a permissive `receive()` function that accepts arbitrary ETH sent directly to the contract and emits the same Funded event without any sender check. This means a non-owner cannot use the `fund()` entrypoint itself, but can still increase the contract balance simply by transferring ETH to the contract address. This is an access-control inconsistency between the documented admin funding path and the actual fallback behavior.
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.