# `LiquidationAccountant.claim()` can be called by anyone causing vault insolvency

LiquidationAccountant.claim() lacked access control, letting anyone call it repeatedly after finalAuctionEnd to decreaseYIntercept and render a PublicVault insolvent.

- Payout: Contest reward
- Severity: high
- Program: Astaria
- Credited: 0xRajeev
- Disclosed: 2022-11-07
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-astaria-judging/issues/188
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-14
- Tags: domain:web3 impact:funds-loss impact:integrity kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** LiquidationAccountant.claim() / PublicVault processEpoch flow
**Root cause:** claim() has no access control and no once-only guard, so any caller can invoke it repeatedly; after finalAuctionEnd it triggers decreaseYIntercept() on the vault.
**Steps:**
1. Wait until a liquidation auction reaches finalAuctionEnd.
2. Call `LiquidationAccountant.claim()` directly from an arbitrary EOA (no auth check).
3. Repeat the call any number of times to repeatedly trigger `decreaseYIntercept()` on the PublicVault.
4. Observe the vault's yIntercept manipulated downward, leaving it insolvent.
**How found:** Code review of the processEpoch flow: noticed claim() is meant to be called by PublicVault but lacks any authorization check, and that it can be invoked repeatedly after finalAuctionEnd.
**Exploitation:** Attacker calls claim() permissionlessly after finalAuctionEnd, repeatedly invoking decreaseYIntercept() on the PublicVault to depress its implied value; fund transfer to LPs is unaffected but the vault becomes insolvent, harming all depositors.
**Insight:** When a function is designed to be called only internally by a trusted contract, verify it actually enforces that caller; also check for missing once-only guards on epoch/settlement functions that mutate accounting state like yIntercept.