1. ReserveLogic.sol

https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/ReserveLogic.sol

function cumulateToLiquidityIndex(
  DataTypes.ReserveData storage reserve,
  uint256 totalLiquidity,
  uint256 amount
) internal returns (uint256) {
  // ((amount / totalLiquidity) + 1) * liquidityIndex -> 이 부분이 원래 활성화 되어 있었음
  uint256 result = (amount.wadToRay().rayDiv(totalLiquidity.wadToRay()) + WadRayMath.RAY).rayMul(
    reserve.liquidityIndex
  );
  reserve.liquidityIndex = result.toUint128();
  return result;
}

((amount / totalLiquidity) + 1) * liquidityIndex 부분이 취약점임

왜 위험한가?

• 유동성 지표 상승 비율이 정확히 (amount / totalLiquidity) + 1) 로 결정됨.

  • amount는 보통 플래시론 프리미엄(수수료) 등 “즉시 분배할 수익”이고,
  • totalLiquidity는 분모(현재 풀의 총 유동성).

• 공격자가 트랜잭션 내 순서 조작(대량 입금→빼기, 플래시론 등)으로

  • 분자(amount)는 크게 만들고

  • 분모(totalLiquidity)는 작게 만들어버리면

    → amount / totalLiquidity 가 비정상적으로 커짐 → liquidityIndex가 한 번에 급등.

• 이 값은 누적 배율이라, 한 번 올라가면 바로 내려가지 않음(시간형 이자처럼 축적되는 개념).

  → 이후 모든 계산식에서 위 값을 이용하여 민팅(입금), 소각(출금)을 하여

  • 민팅할 때 적은 토큰을 주고 많은 토큰을 받을 수 있고,
  • 소각할 때 많은 금액을 인출할 수 있다

2. ScaledBalanceTokenBase.sol

https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/tokenization/base/ScaledBalanceTokenBase.sol

mint

function _mintScaled(
  address caller,
  address onBehalfOf,
  uint256 amount,
  uint256 index
) internal returns (bool) {
  uint256 amountScaled = amount.rayDiv(index);
  require(amountScaled != 0, Errors.INVALID_MINT_AMOUNT);

  ...
  _mint(onBehalfOf, amountScaled.toUint128());
  ...
}

• 입금량을 scaled 토큰으로 바꿀 때 amountScaled = amount / index 를 씀.
• 공격자가 바로 직전에 인덱스를 폭발적으로 키워두면,
  • 같은 실제 입금 amount라도 나눗셈 결과가 극도로 작아짐 → 거의 토큰을 안 받는 효과.
  • require(amountScaled != 0) 가 있어 “완전 0”은 막지만, “아주 작은 1~몇 단위”만 받도록 만들 수 있음.

결과: 터무니없이 적은 토큰을 입금하여 많은 토큰을 받을 수 있음 (0은 제외)