Root + Impact

corruptedClaimDeadline is derived once from _firstGoodFaithCorruptedAt and is never recomputed on subsequent re-flags, so if the moderator corrects the named attacker more than CORRUPTED_CLAIM_WINDOW after the original flag, the newly-named attacker is bound to a deadline that has already passed before they can ever call claimAttackerBounty().

Description

flagOutcome supports pre-claim re-flagging so the moderator can correct a mistake, including renaming the attacker on a good-faith CORRUPTED outcome, as long as no claim has yet been made (claimsStarted == false). This is by design: a claim is treated as the value-movement event that finalizes the outcome, not a timer.
The issue is in how the bounty window is anchored across that correction. _firstGoodFaithCorruptedAt is set exactly once, on the first time the pool ever enters good-faith CORRUPTED, and is deliberately never reset.

corruptedClaimDeadline is always computed from that original timestamp. If the moderator's correction happens after the original 180-day window has already elapsed e.g., they initially mis-typed the attacker's address, later discover the mistake, and fix it well past 180 days later, the freshly-corrected attacker is handed a corruptedClaimDeadline that is already in the past.
claimAttackerBounty() will revert ClaimWindowExpired() on their very first call,

and sweepUnclaimedCorrupted() becomes immediately callable by anyone, sweeping the entire pool (stake + bonus) to recoveryAddress before the correctly-named whitehat ever gets a chance to claim.

Risk

Likelihood:
This occurs whenever a moderator's correction to the attacker address lands more than CORRUPTED_CLAIM_WINDOW (180 days) after the pool's first good-faith CORRUPTED flag a realistic timeline for a DAO-governed correction process.

Impact:
The legitimately-named whitehat attacker permanently loses their entire bounty entitlement (up to the full pool: stake + bonus) with no on-chain recourse. claimAttackerBounty() cannot succeed for them under any circumstance once the inherited deadline has passed.

Proof Of Concept

None

Recommended Mitigation

Only reset the window when the attacker identity actually changes. Re-flagging the same attacker still reuses the original timestamp (preserving the anti-gaming protection), but naming a different attacker now starts a fresh CORRUPTED_CLAIM_WINDOW instead of inheriting one that may already be expired.