A borrower can transfer their debt tokens to the zero address (0x0), effectively burning them. Since liquidations rely on burning the borrower's debt token balance, this action prevents liquidation from properly executing. This allows a borrower to avoid liquidation indefinitely, potentially leading to bad debt accumulation.
This vulnerability allows borrowers to permanently escape liquidation, leading to protocol insolvency. Liquidations depend on burning user debt tokens, so when a user transfers debt tokens to 0x0 address and burn them, liquidators cannot execute liquidations successfully because user has not enough debt token balance to be burned.
Loss of solvency: The protocol accumulates bad debt because borrowers can prevent liquidations.
Potential protocol insolvency: If enough borrowers exploit this issue, the lending pool could become insolvent due to uncollectable debt.
User Borrows Funds
Calls borrow(amount) to receive reserve assets and mint an equivalent amount of debt tokens.
User Transfers Debt Tokens to Zero Address
The _update function ensures debt tokens can't be transferred to other users ( only burning and minting is allowed ), so user transfers debt tokens to address(0), effectively burning them.
Since debt tokens are burned, the user's debt token balance becomes zero.
User Falls Below Liquidation Threshold
Normally, the liquidation process should burn debt tokens and seize the user's collateral.
However, finalizeLiquidation() calls:
Since the user's debt token balance is already zero, this transaction reverts and liquidation fails**, because user has not debt token to be burned**.
User Keeps Borrowed Funds Without Repaying
The user has effectively erased their debt without repayment, preventing liquidation.
This leads to unrecoverable bad debt, causing a protocol deficit.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.