You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
zarkk01 - Liquidations will fail if there is not enough liquidity of the collateral that is supposed to be seized because it has been borrowed from other users.
#304
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
Liquidations will fail if there is not enough liquidity of the collateral that is supposed to be seized because it has been borrowed from other users.
Summary
Liquidity provision from LPs is blended with collaterals deposited by borrowers leading to potential failed liquidations due to no liquidity of the collateral token because it has been borrowed from others.
Vulnerability Detail
The collaterals that a borrower has deposited to back up his debt can be borrowed from other borrowers in a Pool. This can results to scenarios where a borrower can be liquidatable meaning that his collateral have lost value against his debt but the liquidation will not be able to proceed since his collateral amount has been borrowed from another user who deposited another token to back up this debt. The initial liquidatable user seems to have collateral and supplyShares but the actual amount is not in the Pool, so the liquidation will fail to transfer the tokens to the liquidator and to the protocol the fee. To understand better this vulnerability, consider this scenario :
Borrower A deposits 0.1 ETH and borrows some USDC.
ETH price drops making Borrower A liquidatable.
However, another Borrower B borrows the 0.1 ETH and deposits some other token to back it up.
Now, liquidator tries to liquidate Borrower A and get the 0.1 ETH but the tokens are not in the Pool. The value of them is but in other token(that of Borrower B).
We can imagine this exploited in scale and more generally the non-isolated way of mixing the collaterals of the borrowers with liquidity added from LPs. In some extreme scenario, users can exploit this vulnerability by them borrowing the collaterals that are supposed to be seized and prevent their liquidations.
Impact
If the collateral deposited by a borrower has been borrowed by another user, liquidations may fail due to the absence of the collateral in the Pool, even though the collateral's value appears on the borrower’s PositionBalance. This could lead to situations where the protocol cannot recover bad debt during liquidations, potentially causing financial losses to the protocol and affecting its solvency. Moreover, this vulnerability could be exploited at scale, where malicious users borrow collaterals to prevent their liquidation, disrupting the protocol’s liquidation mechanism. As a result, this creates a critical risk to the stability and security of the protocol leading it to bad debt and insolvency.
sherlock-admin3
changed the title
Polished Iris Antelope - Liquidations will fail if there is not enough liquidity of the collateral that is supposed to be seized because it has been borrowed from other users.
zarkk01 - Liquidations will fail if there is not enough liquidity of the collateral that is supposed to be seized because it has been borrowed from other users.
Oct 3, 2024
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
zarkk01
Medium
Liquidations will fail if there is not enough liquidity of the collateral that is supposed to be seized because it has been borrowed from other users.
Summary
Liquidity provision from LPs is blended with collaterals deposited by borrowers leading to potential failed liquidations due to no liquidity of the collateral token because it has been borrowed from others.
Vulnerability Detail
The collaterals that a borrower has deposited to back up his debt can be borrowed from other borrowers in a
Pool
. This can results to scenarios where a borrower can be liquidatable meaning that his collateral have lost value against his debt but the liquidation will not be able to proceed since his collateral amount has been borrowed from another user who deposited another token to back up this debt. The initial liquidatable user seems to have collateral andsupplyShares
but the actual amount is not in thePool
, so the liquidation will fail to transfer the tokens to the liquidator and to the protocol the fee. To understand better this vulnerability, consider this scenario :Pool
. The value of them is but in other token(that of Borrower B).We can imagine this exploited in scale and more generally the non-isolated way of mixing the collaterals of the borrowers with liquidity added from LPs. In some extreme scenario, users can exploit this vulnerability by them borrowing the collaterals that are supposed to be seized and prevent their liquidations.
Impact
If the collateral deposited by a borrower has been borrowed by another user, liquidations may fail due to the absence of the collateral in the
Pool
, even though the collateral's value appears on the borrower’sPositionBalance
. This could lead to situations where the protocol cannot recover bad debt during liquidations, potentially causing financial losses to the protocol and affecting its solvency. Moreover, this vulnerability could be exploited at scale, where malicious users borrow collaterals to prevent their liquidation, disrupting the protocol’s liquidation mechanism. As a result, this creates a critical risk to the stability and security of the protocol leading it to bad debt and insolvency.Code Snippet
https://github.com/sherlock-audit/2024-06-new-scope/blob/main/zerolend-one/contracts/core/pool/logic/LiquidationLogic.sol#L94C1-L197C4
Tool used
Manual Review
Recommendation
Consider using a more isolated way of storing the collaterals of the borrowers up to a certain percentage without allowing to be 100% borrowed.
Duplicate of #198
The text was updated successfully, but these errors were encountered: