# Batched liquidations doesn't distribute bad debt on next batches in the list 

Batched liquidations in eBTC skip redistributing bad debt to subsequent CDPs in the same batch, causing incorrect debt accounting and shifting losses to other stakers.

- Payout: Contest reward
- Severity: medium
- Program: eBTC Protocol
- Credited: rvierdiiev
- Disclosed: 2024-02-13
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-10-badger-findings/issues/36
- Library page: https://bugbountylibrary.com/r/c4%3A2023-10-badger%3AM-06
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium technique:source-review vuln:business-logic vuln:liquidation

**Target:** LiquidationLibrary batchLiquidateCdps
**Root cause:** Redistribution index is not updated after each liquidation within a batch, so subsequent CDPs use stale debt values and bad debt from earlier liquidations is not redistributed to them.
**Steps:**
1. Call `CDPManager.batchLiquidateCdps` with a list of CDPs where an early CDP creates bad debt upon liquidation.
2. Observe that `_finalizeLiquidation` redistributes bad debt only after the entire batch, not after each individual liquidation.
3. Subsequent CDPs in the batch are liquidated using `getSyncedICR` which does not account for the new bad debt, leading to incorrect debt values.
4. As a result, less debt is liquidated and more collateral is returned to the CDP owner, while the unredistributed bad debt is borne by all stakers.
**How found:** Code review of the batch liquidation flow, noticing that redistribution occurs only in `_finalizeLiquidation` after the loop, while `getSyncedICR` uses the current redistribution index which is not updated mid-batch.
**Exploitation:** An attacker could include a CDP that generates bad debt early in a batch liquidation, causing subsequent CDPs to be liquidated with stale debt values, favoring the CDP owners (potentially the attacker) at the expense of other stakers.
**Insight:** In batch operations, state updates that affect subsequent items (like redistribution indices) must be applied per item, not after the loop; check for similar patterns in other protocols with batched liquidations.