Background introduction
On January 12, 2025, we detected an abnormal transaction on the Ethereum chain: https://etherscan.io/tx/0x44037ffc0993327176975e08789b71c1058318f48ddeff25890a577d6555b6ba
After analysis, we found that it was an attack on Unilend, which caused a total loss of about 197k USD.
Attack and incident analysis
First, the attacker borrowed 60,000,000 USDC through Morpho Blue using flashloan.
The attacker then borrowed 5.75 wstETH using a flashloan from Morpho Blue.
Then, unwrap was used to convert the borrowed 5.75 wstETH into 6.85 stETH.
The attacker then used lend to deposit 60,000,000 USDC and 6.85 stETH into UniPool.
Since the attacker has deposited enough collateral, the attacker then successfully borrowed 60.67 stETH from UniPool using borrow.
Then, the attacker used redeemUnderlying to redeem 60,000,000 USDC and 5.75wstETH from UniPool. At this point, the attack was completed.
The vulnerability occurs in redeemUnderlying. Theoretically, the collateral deposited by the attacker has already been partially occupied during borrowing, so the amount deposited in redeemUnderlying should fail, but the attacker succeeded. So, let’s take a look at the specific implementation of redeemUnderlying.
From the code logic, we can see that when amount<0, token0 is exchanged, and when amount>0, token1 is exchanged. The exchange logic is: first calculate the amount tok_amount that can be exchanged, destroy the corresponding LP Position, check the health factor, and transfer it to the user to complete the exchange.
The specific vulnerability appears in checkHealthFactorLtv0 and checkHealthFactorLtv1. The algorithm of check healthfactor is collateral amount x collateral price / (borrowing price x borrowing amount) > 1, but because the user’s collateral amount and borrowing amount are calculated with low allocation, the health factor check can also be passed at this time (theoretically it cannot pass). We can see that the code for calculating collateral amount and borrowing amount is as follows:
When the user has collateral, the contract will calculate whether the value of the collateral is still greater than the value that has been borrowed after this redeem. However, when calculating the value of the collateral after redeem, tokenBalance0 does not subtract the amount that needs to be subtracted for this redeem, and because share has already subtracted the share reduced after this redeem during _burnLPposition. Therefore, _lendBalance0, that is, the amount of collateral, is higher than the amount of collateral actually owned by the attacker.
The attacker finally paid off the 60,000,000 USDC and 5.75 wstETH obtained from Morpho Blue through flashloan, and made a profit of 60.67 stETH, worth 197k USD.
Summary
The cause of this vulnerability is that when Unilend redeem, it did not subtract the amount of collateral that should be transferred out when calculating the amount of collateral, resulting in the amount of collateral after the wrong calculation being higher than the amount of collateral actually owned by the attacker, and the exchange that should not have been successful was successfully completed. Ultimately, the attacker emptied the project’s stETH tokens. It is recommended that the project party conduct multi-party verification when designing the economic model and code operation logic, and try to select multiple audit companies for cross-audit when auditing the contract before it goes online.
