UniLend Finance Hack Analysis

UniLend Finance Hack Analysis

Overview:

On January 13, 2025, the UniLend V2 (@UniLend_Finance) contract on Ethereum was exploited due to incorrect health factor validation in the redeemUnderlying function. The flaw allowed an attacker to manipulate share prices and inflate collateral value, leading to improper health factor calculations. This enabled the attacker to withdraw collateral without adequate checks, resulting in a loss of approximately 61 stETH (~$200k).

Smart Contract Hack Overview:

• Attack Transaction: 0x44037
• Attacker’s Address: 0x55F5f, 0x6a1F5
• UniLendV2Core Contract: 0x7f2E2

Decoding the Smart Contract Vulnerability:

• The root cause of the exploit was the improper health factor validation in the redeemUnderlying function, combined with vulnerabilities in the userBalanceOftoken1 function, and incorrect operation sequencing.

• In the redeemUnderlying function:

LP tokens are burned.

The health factor is checked using the userBalanceOftoken1 function.

Collateral is transferred to the user. However, the health factor calculation is performed using outdated pool balances (token0.balanceOf(address(this)) or token1.balanceOf(address(this))), as the token balances are not updated immediately after burning LP tokens.

• TheuserBalanceOftoken1 function calculates lendBalance using the following logic:
  _lendBalance1 = getShareValue(_totTokenBalance1, _tm1.totalLendShare, _positionMt.token1lendShare);
• Here, _totTokenBalance1 is derived from: tokenBalance1.add(_tm1.totalBorrow);
• Since tokenBalance1 reflects the current contract balance and does not account for tokens already allocated or pending withdrawal, the computation inflates the apparent lendBalance.
• This issue is aggravated when the pool has significant liquidity, allowing a small lending share to correspond to a disproportionately high lendBalance.

So, the sequence of operations in the redeemUnderlying function is flawed like this:
1. LP tokens are burned.
2. The health factor is checked using outdated pool balances.
3. Collateral is transferred to the user.

This order of operations enabled the attacker to exploit the inflated lendBalance calculated before the pool balances are updated.

Instead, a correct sequence would be to update the token balances (via token transfer) before performing the health factor check.

• Also, the getShareByValue function performs the following calculation:return (_valueAmount.mul(_totalSupply)).div(_totalAmount);
This division is prone to rounding errors in favor of the user. A more precise approach would be to use a rounding-up division method (divUp) to ensure the protocol is not over-allocating tokens.

Attack Flow:

• The attacker deposited a massive amount of USDC (60M) into the lending pool, obtaining a small number of lending shares due to the large liquidity in the pool.
• They borrowed stETH and initiated withdrawals using the redeemUnderlying function.
• By exploiting the flawed health factor validation, they managed to withdraw all their USDC while keeping the stETH collateral, resulting in a net gain of approximately 61 stETH (~$200K).

Mitigation and Best Practices:

• Ensure that the health factor is validated after updating the pool’s token balances (via token transfers) and before burning LP tokens or transferring collateral. This prevents the use of outdated balances during health factor calculations, effectively eliminating this exploit vector.
• Adjust the logic to account for in-flight or pending token withdrawals when calculating tokenBalance1 and tokenBalance0. Consider tracking allocated or reserved tokens separately to ensure accurate computations of lendBalance and borrowBalance.
• Always ensure that the contract state (e.g., balances, shares, or pool totals) is updated before performing critical operations such as health factor validations or collateral calculations. This prevents the use of outdated or inconsistent state data.
• Maintain separate variables or mappings for tracking allocated, reserved, or in-flight token amounts. Avoid relying solely on the contract’s balanceOf function to determine the available liquidity or user balances.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 280+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord