Core Contracts

Summary

The vulnerability exists in the debt repayment mechanism (Lines 312-335) of the LendingPool contract. The _repay function uses the ERC20 balanceOf method of the DebtToken to calculate repayable amounts, while the protocol internally tracks debt via the scaledDebtBalance variable. If the DebtToken is transferable (not explicitly restricted), attackers can artificially inflate debt balances to drain protocol reserves or corrupt debt tracking.

Vulnerability Details

Risk Type: High

Technical Analysis

1. DebtToken Transferability:
   By default, ERC20 tokens (like DebtToken) allow transfers unless explicitly restricted. The LendingPool assumes DebtToken balances align 1:1 with user debt. However, transfers break this invariant.

2. Repayment Logic Flaw:
   The _repay function calculates repayable debt as:

   uint256 userDebt = IDebtToken(...).balanceOf(onBehalfOf); // Line 318

   If users receive transferred DebtTokens, their balance exceeds their actual debt (scaledDebtBalance). The protocol allows over-repayment, burning excess tokens and corrupting scaledDebtBalance.

3. Impact Pathways:

   • Over-Repayment Drain: Attackers transfer DebtTokens to victims, tricking them into repaying more than owed. Excess reserves are irreversibly lost.

   • Underflow Corruption: If scaledDebtBalance is reduced below zero (pre-Solidity 0.8), debt tracking becomes invalid.

Impact

1. Protocol Insolvency: Attackers drain reserves by exploiting inflated repayments.

2. Debt Tracking Failure: Negative scaledDebtBalance values disrupt interest calculations.

3. Free Collateral Withdrawal: Users repay inflated debts to withdraw collateral without obligation.

Tools Used

1. Manual Code Review: Identified unsafe reliance on ERC20 balances.

2. Slither: Detected inconsistent state usage between balanceOf and scaledDebtBalance.

3. Hardhat: Simulated token transfers and repayment corruption.

Proof of Concept (PoC)

Overview:

An attacker transfers DebtTokens to a victim, tricking the protocol into accepting over-repayments that drain reserves.

Actors:

• Attacker: Transfers DebtTokens to victims.

• Victim: Repays inflated debt, draining reserves.

• Protocol: Loses assets due to incorrect debt accounting.

Working Test Case:

Recommendations

1. Disable DebtToken Transfers:
   Override ERC20 transfer/transferFrom in DebtToken to revert:

   function transfer(address, uint256) public override returns (bool) {

   revert("DebtToken: Transfers disabled");

   }

2. Use Internal Debt Tracking:
   Replace balanceOf with scaledDebtBalance in repayment logic:

   uint256 userDebt = user.scaledDebtBalance.rayMul(reserve.usageIndex);

3. Add Debt Ownership Checks:
   Restrict repayments to the actual debtor:

   modifier onlyDebtor(address user) {

   require(msg.sender == user, "Unauthorized repayment");

   _;

   }

Conclusion

The transferability of DebtTokens creates a fatal mismatch between ERC20 balances and internal debt tracking, enabling reserve drainage and protocol insolvency. Immediate mitigation requires disabling transfers and aligning repayment logic with internal state.