xanoutas/solidity-security-findings huggingface dataset:
Attacker can theft almost all users that enter the farms by abusing zero id 
Audit: 2024-02-wise-lending-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L210-L252


# Vulnerability details

## Impact
Loss of user funds that enter the power farms

## Proof of Concept
Users who want to leverage their gains enter the power farms by calling;

[enterFarm](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L96) - The NFT id is assigned by calling [_getWiseLendingNFT](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L185) 


[enterFarmETH](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L142) - The NFT id is assigned by calling [_getWiseLendingNFT](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L185) 

And they call [exitFarm](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L210) function when they want to exit the power farms and withdraw their funds from the farms.

---

Bob is a malicious actor and he doesn´t possess any Position NFT or Power Farm NFT or any reservations. In addition, for the simplicity, there´s no available Power Farm NFT for the latter assignment (availableNFTCount == 0 condition)

1. He simply calls `exitFarm` with `_keyId = 0`

For the call trace, `exitFarm` logic is as follows;
```solidity
Contract: PendlePowerManager.sol

210:     function exitFarm(
211:         uint256 _keyId,
212:         uint256 _allowedSpread,
213:         bool _ethBack 
214:     )
215:         external
216:         updatePools
217:         onlyKeyOwner(_keyId)
218:     {
219:         uint256 wiseLendingNFT = farmingKeys[
220:             _keyId
221:         ];
222: 
223:         delete farmingKeys[
224:             _keyId
225:         ];
226: 
227:         if (reservedKeys[msg.sender] == _keyId) {
228:             reservedKeys[msg.sender] = 0;
229:         } else {
230:             FARMS_NFTS.burnKey(
231:                 _keyId
232:             );
233:         }
234: 
235:         availableNFTs[
236:             ++availableNFTCount
237:         ] = wiseLendingNFT;
238: 
239:         _closingPosition(
240:             isAave[_keyId],
241:             wiseLendingNFT,
242:             _allowedSpread,
243:             _ethBack
244:         );
245: 
246:         emit FarmExit(
247:             _keyId,
248:             wiseLendingNFT,
249:             _allowedSpread,
250:             block.timestamp
251:         );
252:     }
```
2. Supplied keyId is validated by `onlyKeyOwner(_keyId)` modifier call;
```solid
Assigning available NFTs in PendlePowerManager leads to position thefts
Audit: 2024-02-wise-lending-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L235-L237


# Vulnerability details

## Impact
Loss of user funds

## Proof of Concept
The `PowerFarmNFT`s are vital for the protocol as the positions being held in the farms are represented by the ID of the `PowerFarmNFT`.

If the user wants to leverage their gains by entering Power Farms they call;

[enterFarm](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L96) - The NFT id is assigned by calling [_getWiseLendingNFT](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L185) 

[enterFarmETH](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L142) - The NFT id is assigned by calling [_getWiseLendingNFT](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L185) 


Let´s check the user flow to understand how the positions are handled.

Alice holds a Position NFT and she wants to leverage her gains by the farms.

1. Alice calls [enterFarm](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarm/PendlePowerManager.sol#L96)

`enterFarm` logic is below;
```solidity
Contract: PendlePowerManager.sol

 96:     function enterFarm(
 97:         bool _isAave,
 98:         uint256 _amount,
 99:         uint256 _leverage,
100:         uint256 _allowedSpread
101:     )
102:         external
103:         isActive
104:         updatePools
105:         returns (uint256)
106:     {
107:         uint256 wiseLendingNFT = _getWiseLendingNFT();
108: 
109:         _safeTransferFrom(
110:             WETH_ADDRESS,
111:             msg.sender,
112:             address(this),
113:             _amount
114:         );
115: 
116:         _openPosition(
117:             _isAave,
118:             wiseLendingNFT,
119:             _amount,
120:             _leverage,
121:             _allowedSpread
122:         );
123: 
124:         uint256 keyId = _reserveKey(
125:             msg.sender,
126:             wiseLendingNFT
127:         );
128: 
129:         isAave[keyId] = _isAave;
130: 
131:         emit FarmEntry(
132:             keyId,
133:             wiseLendingNFT,
134:             _leverage,
135:             _amount,
136:             block.timestamp
137:         );
138: 
139:         return keyId;
140:     }
```
2. L: 103 & L: 104 are the modifiers and they do the following;
[isActive](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/Pendl
Potential Loss of Arbitrage Rewards Due to Master Account Set to Zero Address in PendlePowerFarmController
Audit: 2024-02-wise-lending-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/OwnableMaster.sol#L103-L114
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarmController/PendlePowerFarmController.sol#L431-L449


# Vulnerability details


## Impact
The issue arises when the master account in the `PendlePowerFarmController` contract is set to the zero address, potentially leading to the permanent loss of arbitrage rewards. This situation occurs when the `renounceOwnership` function is called, which sets the master account to the zero address. Subsequently, if the `claimArb` function is invoked to claim and transfer arbitrage rewards, these tokens are sent to the zero address, effectively burning them. This could result in a significant loss of funds intended for management or distribution by the master account.

## Scenario
Consider a scenario involving the WiseLending protocol, where the protocol owner, Bob, decides to renounce ownership. Bob executes the `renounceOwnership` function, setting the master account to the zero address. After this action, Bob or another party might invoke the `claimArb` function to claim and transfer arbitrage rewards. However, since the master account is now the zero address, any tokens transferred via the `claimArb` function will be lost permanently.

## Proof of Concept

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/OwnableMaster.sol#L103-L114
- **Code Snippet for `renounceOwnership` from the `OwnableMaster.sol**:
```solidity
function renounceOwnership()
    external
    onlyMaster
{
    master = ZERO_ADDRESS;
    proposedMaster = ZERO_ADDRESS;

    emit RenouncedOwnership(
        msg.sender
    );
}
```

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarmController/PendlePowerFarmController.sol#L431-L449
- **Code Snippet for `claimArb` Function from `PendlePowerFarmController.sol`**:
```solidity
function claimArb(
    uint256 _accrued,
    bytes32[] calldata _proof
)
    external
    onlyArbitrum
{
    ARB_REWARDS.claim(
        master, // This will be the zero address after renouncing ownership
        _accrued,
        _proof
    );

    emit ClaimArb(
        _accrued,
        _proof,
        block.timestamp
    );
}
```

A Proof of Concept (POC) demonstrating the issue would involve:
1. Deploying the `PendlePowerFarmController` contract with a specific master account.
2. Invoking the `renounceOwnership` function to set the master account to the zero address.
3. Attempting to invoke the `claimArb` function to claim and transfer arbitrage rewards.
4. Observing that the tokens are sent to the zero address, effectively burning them.

## Tools Used
Manual Review

## Recommended Mitigation Steps
1. **Introduce a Dedicated Account for Collecting Arbitra
Potential Loss of Tokens Due to Master Account Set to Zero Address in PendlePowerFarmController
Audit: 2024-02-wise-lending-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarmController/PendlePowerFarmController.sol#L172-L208
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/OwnableMaster.sol#L103-L114


# Vulnerability details

## Impact
The issue arises when the master account in the `PendlePowerFarmController` contract is set to the zero address, potentially leading to the permanent loss of tokens. This situation occurs when the `renounceOwnership` function is called in the `OwnableMaster.sol`, which sets the master account to the zero address. Subsequently, if the `skim` function is invoked to transfer excess tokens above LP assets in Pendle Power Farms, these tokens are sent to the zero address, effectively burning them. This could result in a significant loss of funds.

## Scenario
Consider a scenario involving the WiseLending protocol, where the protocol owner decides to decentralize the protocol by renouncing ownership. The protocol owner, Alice, executes the `renounceOwnership` function, setting the master account to the zero address. After this action, Alice or another party might invoke the `skim` function to transfer excess tokens above LP assets in Pendle Power Farms. However, since the master account is now the zero address, any tokens transferred via the `skim` function will be lost permanently.

## Proof of Concept

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/OwnableMaster.sol#L103-L114
- **Code Snippet for `renounceOwnership` from the `OwnableMaster.sol`**:
```solidity
function renounceOwnership()
    external
    onlyMaster
{
    master = ZERO_ADDRESS;
    proposedMaster = ZERO_ADDRESS;

    emit RenouncedOwnership(
        msg.sender
    );
}
```

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/PowerFarms/PendlePowerFarmController/PendlePowerFarmController.sol#L172-L208
- **Code Snippet for `skim` Function from `PendlePowerFarmController.sol`**:
```solidity
function skim(
    address _pendleMarket
)
    external
    returns (uint256)
{
    // Function implementation...
    _safeTransfer(
        _pendleMarket,
        master, // This will be the zero address after renouncing ownership
        difference
    );
    // Function implementation...
}
```

A POC demonstrating the issue would involve:
1. Deploying the `PendlePowerFarmController` contract with a specific master account.
2. Invoking the `renounceOwnership` function to set the master account to the zero address.
3. Attempting to invoke the `skim` function to transfer excess tokens above LP assets in Pendle Power Farms.
4. Observing that the tokens are sent to the zero address, effectively burning them.

## Tools Used
Manual Review

## Recommended Mitigation Steps
1. **Introduce a Dedicated Account for Collecting Additio
Vulnerability in WiseCore._withdrawOrAllocateSharesLiquidation due to misuse of integer division in the presence of low-decimal tokens.
Audit: 2024-02-wise-lending-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-02-wise-lending/blob/main/contracts/WiseCore.sol#L460


# Vulnerability details

## Impact

- The vulnerability in the `_withdrawOrAllocateSharesLiquidation` function of the WiseCore contract poses a significant threat to the Wise Lending protocol and its users. If exploited, it could lead to a devastating loss of funds and undermine the protocol's integrity. The potential impact of this vulnerability is as follows:

1. **Substantial Financial Losses**: An attacker can manipulate the liquidation process by exploiting the vulnerability in the `_withdrawOrAllocateSharesLiquidation` function. By repeatedly liquidating positions with carefully crafted parameters, the attacker can withdraw more shares than intended, gradually draining the protocol's liquidity pools. This could result in substantial financial losses for the protocol and its users, potentially amounting to millions of dollars.

2. **Systemic Risk**: The vulnerability not only affects individual users but also poses a systemic risk to the entire Wise Lending ecosystem. If the attacker manages to drain a significant portion of the liquidity pools, it could trigger a cascade of liquidations and defaults, leading to a collapse of the lending and borrowing system. The ripple effects could extend beyond the Wise Lending protocol, impacting other interconnected DeFi protocols and the broader ecosystem.

## Proof of Concept

Code snippet: 





```solidity
    function _withdrawOrAllocateSharesLiquidation(
        uint256 _nftId,
        uint256 _nftIdLiquidator,
        address _poolToken,
        uint256 _percentWishCollateral
    )
        private
        returns (uint256)
    {
        uint256 product = _percentWishCollateral
            * userLendingData[_nftId][_poolToken].shares;

        uint256 cashoutShares = product / PRECISION_FACTOR_E18 + 1;

        uint256 withdrawAmount = _cashoutAmount(
            _poolToken,
            cashoutShares
        );

        uint256 totalPoolToken = globalPoolData[_poolToken].totalPool;

        if (withdrawAmount <= totalPoolToken) {

            _coreWithdrawBare(
                _nftId,
                _poolToken,
                withdrawAmount,
                cashoutShares
            );

            return withdrawAmount;
        }

        uint256 totalPoolInShares = calculateLendingShares(
            {
                _poolToken: _poolToken,
                _amount: totalPoolToken,
                _maxSharePrice: false
            }
        );

        uint256 shareDifference = cashoutShares
            - totalPoolInShares;

        _coreWithdrawBare(
            _nftId,
            _poolToken,
            totalPoolToken,
            totalPoolInShares
        );

        _decreaseLendingShares(
            _nftId,
            _poolToken,
            shareDifference
        );

        _increasePositionLendingDeposit(
            _nftIdLiquidator,
            _poolToken,
            share
Tokens are not been send it to the user in the aave hub contract.
Audit: 2024-02-wise-lending-findings
Severity: HIGH

# Lines of code

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


# Vulnerability details

When a user deposit through the aave hub this is the order of the events:
1. the tokens are send it to the aave hub contract from the user through the deposit function.
2. the token are supplied in the aave lending protocol and aave hub mint some atokens.
3. This atokens are depositing to the wiseLending main contract.

When a user want to borrow or witdraw  this is the order of the events:
1. The atoken are send it from the wiseLending main contract to the aave hub.
2. this atoken are been burned, in the avee hub 
3. the underlying token is send it back to the user.

The problem is that the tokens are never send it back to the user.

## Impact
User loss his money borrowing or withdrawing tokens (This not affect function using eth directly) in the aave hub because the contract is never send it back the token to the user.

## Proof of Concept
If we follow the orden present in the begining:

```
file:/contracts/WrapperHub/AaveHub.sol

function depositExactAmount(
        uint256 _nftId,
        address _underlyingAsset,
        uint256 _amount
    )
        public
        nonReentrant
        validToken(_underlyingAsset)
        returns (uint256)
    {
        _safeTransferFrom(  <------
            _underlyingAsset,
            msg.sender,
            address(this),
            _amount
        );

        uint256 lendingShares = _wrapDepositExactAmount(  <-----
            _nftId,
            _underlyingAsset,
            _amount
        );

        emit IsDepositAave(
            _nftId,
            block.timestamp
        );

        return lendingShares;
    }
```
[[Link]](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WrapperHub/AaveHub.sol#L122C5-L151C6)

When you deposit the token are been send it to the aave hub and in the _wrapDepositExactAmount the contract is suplying in the aave protocol and depositing on the wiseLending on behalf of the user.

Now when a user atemp to withdraw:

```
file:/contracts/WrapperHub/AaveHub.sol

 function withdrawExactShares(
        uint256 _nftId,
        address _underlyingAsset,
        uint256 _shareAmount
    )
        external
        nonReentrant
        validToken(_underlyingAsset)
        returns (uint256)
    {
        _checkOwner(
            _nftId
        );

        uint256 withdrawAmount = _wrapWithdrawExactShares(  <------
            _nftId,
            _underlyingAsset,
            msg.sender,
            _shareAmount
        );

        emit IsWithdrawAave(
            _nftId,
            block.timestamp
        );

        return withdrawAmount;
    }
```
[[Link]](https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WrapperHub/AaveHub.sol#L281)

```
function _wrapWithdrawExactShares(
        uint256 _
Potential Loss of Funds Due to Zero Address as Master in WiseLending Contract
Audit: 2024-02-wise-lending-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L46-L61
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/OwnableMaster.sol#L92-L114


# Vulnerability details

## Impact
If the master address in the `WiseLending contract` is set to the zero address, any ETH sent directly to the contract will be permanently lost. This is because the zero address is not a valid address and cannot receive Ether. This issue can be exploited by anyone who has the ability to call the `renounceOwnership()` function, which sets the master address to the zero address.


## Proof of Concept
Alice, as the user, sends funds directly to the `WiseLending contract` using a low-level call with an empty data parameter. The `receive` function is triggered, and the ETH is forwarded to the `master` address.

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L46-L61

```solidity
receive()
    external
    payable
{
    if (msg.sender == WETH_ADDRESS) {
        return;
    }

    _sendValue(
        master,
        msg.value
    );
}
```

Alice then calls the `renounceOwnership()` function in the `OwnableMaster.sol`, which sets the `master` address to the zero address.
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/OwnableMaster.sol#L92-L114

```solidity
function renounceOwnership()
    external
    onlyMaster
{
    master = ZERO_ADDRESS;
    proposedMaster = ZERO_ADDRESS;

    emit RenouncedOwnership(
        msg.sender
    );
}
```
Alice, or any other user, attempts to send funds directly to the `WiseLending` contract again. The `receive` function is triggered, but since the master address is now the zero address, the `_sendValue` function will attempt to send the ETH to the zero address, resulting in a permanent loss of funds.

```solidity
_sendValue(
    master,
    msg.value
);
```


## Tools Used
Manual review

## Recommended Mitigation Steps
Add a check in the `receive` function in the `WiseLending.sol` to ensure that the `master` address is not the zero address before attempting to forward the ETH or the transaction should revert if the `master` address is zero.


## Assessed type

Other