The position of the aaveHub can be liquidate if aave contract is in pause

[c4-bot-1]

Lines of code

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WrapperHub/AaveHelper.sol#L101

Vulnerability details

One of the known issues is the issue presented below:

" If Aave freezes pools where we use the underlying as a pool new aTokens can't be minted and thus open borrow positions can't pay it back. If Aave unfreezes the pool the functionality is restored. This can be mitigated in the future by wrapping the aTokens into new tokens which also accept the underlying. Then after adding that to a pool this is mitigated. So the risk is known and not considered a bug and can be migrated after launch while its still not frozen. "

The problem is that is user can not payback, but they can get liquidate.

Impact

Users can not pay back his borrow If Aave freezes pools, but the contract is not taking in consideration that they are still open to liquidation which is no fair for users.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

Tools Used

As you can see the entry point of the liquidation is:

file:/contracts/WiseLending.sol

function liquidatePartiallyFromTokens(
        uint256 _nftId,
        uint256 _nftIdLiquidator,
        address _paybackToken,
        address _receiveToken,
        uint256 _shareAmountToPay
    )
        external
        syncPool(_paybackToken)
        syncPool(_receiveToken)
        returns (uint256)
    {
        CoreLiquidationStruct memory data;

        data.nftId = _nftId;
        data.nftIdLiquidator = _nftIdLiquidator;

        data.caller = msg.sender;

        data.tokenToPayback = _paybackToken;
        data.tokenToRecieve = _receiveToken;
        data.shareAmountToPay = _shareAmountToPay;

        data.maxFeeETH = WISE_SECURITY.maxFeeETH();
        data.baseRewardLiquidation = WISE_SECURITY.baseRewardLiquidation();

        (
            data.lendTokens,
            data.borrowTokens
        ) = _prepareAssociatedTokens(
            _nftId,
            _receiveToken,
            _paybackToken
        );

        data.paybackAmount = paybackAmount(
            _paybackToken,
            _shareAmountToPay
        );

        _checkPositionLocked(
            _nftId,
            msg.sender
        );

        _checkLiquidatorNft(
            _nftId,
            _nftIdLiquidator
        );

        WISE_SECURITY.checksLiquidation(
            _nftId,
            _paybackToken,
            _shareAmountToPay
        );

        return _coreLiquidation(
            data
        );
    }

[Link]

This function is not taking in consideration is the aave lending is in paused, so User can't pay back his borrow but they still can be liquidate.

Recommended Mitigation Steps

Consider don't allow liquidation on the aave tokens pool if aave freeze their pools

Assessed type

Other

[vm06007]

This was mentioned in HatsFinance competition already and also was OOS (out of scope) in both competitions. This can be dismissed due to being out of scope and because it was clearly communicated that risks involving Aave being upgradable contract or simply freezing pools is centralized risk, hence not part of the audit scope.

Also theoretically it is invalid statement that users won't be able to repay their positions, we've already anticipated such scenario and it is always possible to offer a wrapper contract to solve this by allowing users paying back and not being liquidated. This is also why we did not include in the scope because this problem can be solved by additional contract should it occur. Users can use native pools. Aave pools always expose to risk with Aave being upgradable.

[c4-pre-sort]

GalloDaSballo marked the issue as primary issue

[c4-pre-sort]

GalloDaSballo marked the issue as insufficient quality report

[GalloDaSballo]

Please see the sponsors comment

[c4-judge]

trust1995 marked the issue as unsatisfactory: Out of scope