# Protection can be bought in late pools, allowing buyers to pay minimal premium and increase the chance of a compensation

Carapace cached pool status lets buyers purchase protection on already-late Goldfinch pools at minimal premium, raising compensation odds.

- Payout: Contest reward
- Severity: medium
- Program: Carapace
- Credited: rvierdiiev
- Disclosed: 2023-02-01
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-carapace-judging/issues/252
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-carapace%3AM-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:race-window technique:source-review vuln:accounting-error vuln:business-logic

**Target:** ProtectionPool.buyProtection / DefaultStateManager pool status cache
**Root cause:** _verifyLendingPoolIsActive reads a cached poolStatus that is only refreshed by scheduled assessStates calls, so a pool that became late in Goldfinch still appears active in Carapace until the next assessment.
**Steps:**
1. Observe pool is Active in Carapace after last assessStates call.
2. Pool misses a repayment in Goldfinch, becoming late, but Carapace status is stale.
3. Front-run the next assessStates call and call `buyProtection` with minimal duration/premium; `_verifyLendingPoolIsActive` passes on stale status.
4. assessStates then flips status to LateWithinGracePeriod, blocking further purchases.
5. If pool defaults, buyer collects compensation on cheaply-bought protection.
**How found:** Code reading of _verifyLendingPoolIsActive revealed it trusts a cached poolStatus not updated within buyProtection, and that status refresh happens only in separately-triggered assessStates/assessStateBatch, creating a stale-state window.
**Exploitation:** Buyer monitors Goldfinch repayment status off-chain, detects a missed payment before the scheduled assessStates refresh, and front-runs the refresh transaction with a minimal-duration, minimal-premium buyProtection call to be eligible for compensation on a likely-defaulting pool.
**Insight:** When a guard reads a cached status field, check what refreshes it and whether the refresh is caller-triggered or scheduled; any gap between real-world state change and cache update is a front-runnable window for logic abuse.
