# Borrower can use liquidationInitialAsk to block future borrowers

A lender's low liquidationInitialAsk on a later lien makes the stack-wide potentialDebt check revert, permanently blocking the borrower from any further borrowing.

- Payout: Contest reward
- Severity: high
- Program: Astaria
- Credited: obront
- Disclosed: 2023-05-22
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-01-astaria-findings/issues/289
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-astaria%3AH-12
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** LienToken.sol _appendStack / _buyoutLien stack validation
**Root cause:** The potentialDebt-vs-liquidationInitialAsk check is applied to every lien in the stack, but only stack[0]'s liquidationInitialAsk is used as the Seaport auction start price; later liens' values serve no purpose except to revert future borrows.
**Steps:**
1. Borrower has an existing loan; stack[0] lien sets the auction price.
2. Attacker lends with liquidationInitialAsk set exactly equal to their loan amount.
3. Attacker's lien is appended to the borrower's stack with that low value recorded.
4. Any subsequent borrow calls _appendStack, accumulating potentialDebt across the stack and comparing to each lien's liquidationInitialAsk.
5. Since futureBorrow + existingDebt > attacker's liquidationInitialAsk, the check reverts with INITIAL_ASK_EXCEEDED, blocking all future borrows.
**How found:** Code reading of _appendStack/_buyoutLien revealed the per-lien check, then cross-referencing Router#liquidate showed only stack[0].liquidationInitialAsk is actually used, making later checks pure DoS surface.
**Exploitation:** Attacker (a lender) sets a minimal liquidationInitialAsk on their lien; once accepted onto the victim borrower's stack, every future borrow reverts, DoSing the borrower until they repay or refinance on rate/duration terms.
**Escalation:** liquidationInitialAsk cannot justify a refinance, so the borrower cannot easily escape the DoS via refinancing.
**Insight:** When a validation loops over a stack but downstream logic only consumes index 0, per-element checks on the other elements are attacker-controllable DoS levers — trace which stack element each field is actually read by.