The constructor correctly validates if (_verifier == address(0)) revert InvalidVerifier().
updateVerifier(), which replaces the verifier at runtime, performs no such check, allowing the owner to accidentally (or maliciously, post-key-compromise) set the verifier to address(0) or any non-contract address.
Likelihood:
Requires a compromised or negligent owner key unlikely but non-zero.
Impact:
Setting verifier = address(0) causes verifier.verify(...) to revert on all future claim() calls, permanently bricking the hunt without a recovery path while the contract still holds funds.
Even if caught quickly, the contract must be unpaused → re-paused → verifier updated, during which time the hunt is halted.
Mirror the constructor's validation in updateVerifier():
The issue is that `updateVerifier()` allows the owner to replace the verifier with an arbitrary address, including `address(0)`, even though the constructor explicitly treats a zero verifier as invalid and reverts with `InvalidVerifier()` during initial deployment. In other words, the contract establishes at deployment time that a null verifier address is not an acceptable configuration, but then fails to preserve that same invariant when the verifier is later updated through the admin recovery path.
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.