xanoutas/solidity-security-findings huggingface dataset:
Swapped parameters when calling `createEscrow()`
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketBase.sol#L173-L174
https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketWithdrawals.sol#L167-L168


# Vulnerability details



## Impact
`getEscrowAddress()` returns the wrong WildcatSanctionsEscrow.
Borrower can steal lender's escrowed funds.

## Proof of concept
[`createEscrow()`](https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/WildcatSanctionsSentinel.sol#L95-L98) and [`getEscrowAddress()`](https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/WildcatSanctionsSentinel.sol#L65-L68) both take the parameters `borrower`, `account`, `asset`, in that order, as defined in WildcatSanctionsSentinel.sol.
However, where `createEscrow()` is used, [in `WildcatMarketBase._blockAccount()`](https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketBase.sol#L173-L174) and [in `WildcatMarketWithdrawals.executeWithdrawal()`](https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketWithdrawals.sol#L167-L168), the intended `borrower` and `account` have swapped places.

This means that `getEscrowAddress(borrower, account, asset)` returns a different address. The immediate implication of this is that a user or contract interfacing with `getEscrowAddress()` will be unable to find the correct WildcatSanctionsEscrow.

Furthermore, the `borrower` and `account` will then have swapped places also in the deployed WildcatSanctionsEscrow. This means that `canReleaseEscrow()` now returns `!WildcatSanctionsSentinel(sentinel).isSanctioned(account, borrower);` which most likely is `true` since it was the `account` that was sanctioned, not the `borrower`. Then the borrower can `releaseEscrow()` which will now `IERC20(asset).transfer(borrower, amount);`. That is, the borrower can immediately transfer the lender's escrowed funds to himself.

`createEscrow()` will now also set `sanctionOverrides[account][escrowContract] = true;`, which seems less of an issue.

## Recommended mitigation steps
Correct the order of the parameters [in `WildcatMarketBase._blockAccount()`](https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketBase.sol#L173-L174) and [in `WildcatMarketWithdrawals.executeWithdrawal()`](https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketWithdrawals.sol#L167-L168).


## Assessed type

Context
TRANSFERING FUNDS TO YOURSELF INCREASES YOUR BALANCE
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/main/src/market/WildcatMarketToken.sol#L54
https://github.com/code-423n4/2023-10-wildcat/blob/main/src/market/WildcatMarketToken.sol#L74
https://github.com/code-423n4/2023-10-wildcat/blob/main/src/market/WildcatMarketToken.sol#L78


# Vulnerability details

## Impact
If transferred to yourself, it will cause your balance to increase, thus growing the token balance infinitely.

## Proof of Concept
```solidity
File: src/market/WildcatMarketToken.sol

54:     _transfer(from, to, amount);

74:     _accounts[from] = fromAccount;

78:     _accounts[to] = toAccount;

```

## Tools Used
VS Code

## Recommended Mitigation Steps
Add checks to make sure that `_from != _to` because that shouldn’t be useful anyway


## Assessed type

Invalid Validation
Sanction Bypass Through Transferring to another account
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketToken.sol#L36-L39


# Vulnerability details

## Impact
Wildcat protocol provides lending with lender backed collateral (considered as reserves and the ratio must be upheld by the borrower). WildcatMarketTokens are provided to lenders in return for their base assets, these tokens are ERC20 meaning tokens can be transferred to and from different users. The protocol team has taken certain steps to prevent interaction with sanctioned users which will send funds to an escrow contract to be held until their sanction status is revoked of a borrower accepts strict liability by overriding their sanction status.

Wildcat does not check sanctions on transfer which can lead lenders who are sanctioned to avoid having their funds locked in the designated escrow contract.

## Proof of Concept
Consider the following scenario;

1. Assume a wildcat market exists with a lender approved. This lender has deposited an amount of funds and later was sanctioned by Chain Analysis Sentinel
2. If the lender realises they are sanctioned, they can transfer the ERC20 tokens to another account and complete withdrawal process from a non-sanctioned account.

It is worth noting that there are restrictions on this, namely there is a delay between queueing withdrawal and executing withdrawals. This does provide chain-analysis time to update the list which means the bypass is not guaranteed.

## Tools Used
Manual Review

## Recommended Mitigation Steps

Lenders should have sanction status checked when transferring MarketTokens


## Assessed type

ERC20
Sanction Bypass Through Depositing to Authorized Borrower's Market
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarket.sol#L86-L91


# Vulnerability details

## Impact
Wildcat protocol provides lending with lender backed collateral (considered as reserves and the ratio must be upheld by the borrower). The protocol team has taken certain steps to prevent interaction with sanctioned users. However, sanction status is only verified on withdrawal meaning sanction bypasses can occur.

The protocol focuses on validating if approved lenders are sanctioned at some point after market creation and correctly proceed to lock their funds. However by doing this;

1. They ignore accounts that have already been sanctioned. This imposes strictl liability issues on the borrower, as they are actively interacting with accounts that are deemed as 'sanctioned' by chain analysis sentinel.

2. A sanctioned lender account address could use a willing/authorised borrower address as a proxy to bypass sanction limitations. Meaning a sanctioned user could send money to an approved market

## Proof of Concept
Consider the following scenario;

1. WildcatArchController.registerBorrower(): Borrower is approved at the ArchController level
2. WildcatMarketControllerFactory.deployController(): Borrower calls this function to deploy a controller, alternatively, they can call deployControllerAndMarket() to initialise the market in one step.
3. WildcatMarketController.deployMarket(): Borrower or Controller calls this to create a market. Enforcement of parameters used is done to check bounds of market parameters.
4. WildcatMarketController.authorizeLender(): Borrower authorises lender. No check here is performed to see if the lender is sanctioned, meaning sanctioned lenders can be added to the system. Assume lender who is added is sanctioned.
5. WildcatMarketController.updateAccountAuthorization(): Borrower then pushes these authorizations to the MarketConfig's account list
6. WildcatMarket.deposit(): authorised lender, then deposits an amount to the market. In return the lenders account.scaledBalance is pushed up indicating he now holds market tokens.

From here the borrower is able to use these funds as he pleases and the fees of lending will increment the account balancdeds of the sanctioned lender.

The following caveats should be considered;
1. Lenders sanction status can be overridden by a borrower, this is current accepted behaviour. But in this case the borrower is actively accepting the strict liability risks with dealing with this lender. In the above example there is no acceptance of this strict liability and the scenario presented the lender could be added on a sanction list before or after being approved by the borrower until any time before depositing.

2. Borrowers may be incentivised to act as laundering proxies both actively by dealing with , or inadvertently through accepting lenders who may own significant share of reservers and 


* tests can be provid
Single lender can game markets into unexpected states of delinquency
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketToken.sol#L41-L45
https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarket.sol#L53


# Vulnerability details

## Impact
Wildcat Markets allow for for a borrower to accept the risks they are willing to manage when agreeing to terms of uncollatoralised lending. Namely authorised borrowers will permit certain lenders and control certain market parameters like interest rate, reserve ratio and delinquency fees [verify]. 

It is important to understand what risks the lender and borrower willingly take on. The borrower can accept the risk that a lender will pull out of the market potentially plunging his market into a state of delinquency. The borrower can accept the risk of how many lenders they are willing to take on, the amount of the loan and the reserve ratio that are willing to have. The borrower attempts where possible to control the environment to ensure they can repay the lenders and maintain reserve ratios to avoid delinquency. However, the borrower is incapable of controlling maximum deposit size per lender, this means that a single lender in a multi-lender approved market can take up the entirety of the market token ownership.

If a market has a single lender, the entirety of the reserve ratio ratio could be withdrawn. This behaviour can be both unintended, and detrimental side-effects as it will place the borrower in a situation where they will instantly have to recover the entire reserve amount, this risk of delinquency could be unwanted and unavoidable. By plunging the account into delinquency, the remaining shares will acrue fees from the lender at a higher rate than normal, further amplifying the likelihood that a lender may actively try to game a borrower's market.

## Proof of Concept
This is a strategic attack as opposed to a low level technical issue, as such a written proof of concept is illustrated below:

1. A borrower creates a market.
2. Borrower approves 5 lenders, accepting they can tolerate at least a sudden 20%-40% drop in reserves if a certain number of lenders suddenly liquidate their positions. It is true that all lenders can withdraw in the same batch, but delinquency rates are paid to those who remain, allowing a borrower to probablistically determine how much is needed to keep the reserve ratio healthy.
3. A single borrower capitalises on the entire market position.
4. If they withdraw most of their funds, the remaining funds will acrue a delinquency fee if the market borrower is unable to return the reserve balance to the required reserveRatio.

* tests can be provided upon request to assist the audit team.

## Tools Used
Manual Review

## Recommended Mitigation Steps
Provide an additional market parameter which allows borrrowers to stipulate maximum percentage of market control by each lender. This value would need to be check
potential griefing attack on deployMarket
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/WildcatMarketController.sol#L291-L360


# Vulnerability details

## Impact
potential griefing attack on deployMarket by malicious borrowers 
## Proof of Concept
when borrwer try to deployMarket , malicious borrower see paramenters of the deploymarket in transaction pool, take those parameters and deploy market by front runnning 

      bytes32 salt = _deriveSalt(asset, namePrefix, symbolPrefix);
    market = LibStoredInitCode.calculateCreate2Address(ownCreate2Prefix, salt, marketInitCodeHash);
    if (market.codehash != bytes32(0)) {
      revert MarketAlreadyDeployed();
    }

if the market is alrdy deployed , transaction will be reverted , malicious borrower gonna take  that market.If other borrowers deployed market with same asset ,name and symbol , they can't deploy more ,
## Tools Used
manual view
## Recommended Mitigation Steps
add hash of msg.sender address to salt, salt will be totally different from others and there will not be same market.codehash. Then borrowers can deploy market with same asset ,name and symbol , 


## Assessed type

DoS
InterestRate can be changed during close market.
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketConfig.sol#L149-L159


# Vulnerability details

## Summary 
After closing market, the borrower can set the interest rate.
## Impact
Breaking calculations, loss of funds.

## Vulnerability Details 
After borrower closed the market, he can set interest rate, this means remaining totalSupply still earn interest while it can't be paid.

## Tools Used
Manual Review 
## Recommended Mitigation Steps
Check market status in setAnnualInterest.


## Assessed type

Other
_blockAccount doesn’t transfer asset correctly getting portion of funds locked permanently
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarketBase.sol#L178


# Vulnerability details

## Description

When ```_blockAccount``` is called and the account that is getting blocked has balance in the market, escrow contract is created and balance of the user is transferred to this contract by updating ```_accounts``` mapping. When the account is unsanctioned, the balance that escrow contract owns has to be transferred back to the account. However there are no ways for transferring this balance back to the account unless borrower borrows all the balance available and gives them back in other way. Still this results in portion(reserve ratio) of funds getting locked permanently. 

## PoC

```solidity
// SPDX-License-Identifier: NONE
pragma solidity >=0.8.20;

import "forge-std/console.sol";

import './BaseMarketTest.sol';

contract Exploit is BaseMarketTest {
    function testBlockAccount() external {
        address carol = address(0xcccc);
        address escrow;

        _deposit(carol, 1e18);
        console.log("Carol's scaledBalance : %s", market.scaledBalanceOf(carol));

        // Carol is sanctioned and nukeFromOrbit(_blockAccount) is called to lock the asset
        sanctionsSentinel.sanction(carol);
        vm.recordLogs();
        market.nukeFromOrbit(carol);

        // Get escrow address
        Vm.Log[] memory entries = vm.getRecordedLogs();
        for (uint256 i=0; i<entries.length; i++) {
            if (entries[i].topics[0] == keccak256("Transfer(address,address,uint256)")) {
                escrow = address(uint160(uint256(entries[i].topics[2])));
            }
        }

        // Although Escrow contract's scaledBalance is updated, their is no way of transferring this balance. 
        console.log("Escrow contract scaledBalance : %s", market.scaledBalanceOf(escrow));
    }
}
```

## Tools Used

Visual Studio Code, Foundry 

## Recommended Mitigation Steps

Add a new method which moves ```scaledBalance``` back to account from escrow contract when sanction is removed. 





## Assessed type

Context
Denial of service to closeMarket.
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/market/WildcatMarket.sol#L142-L162


# Vulnerability details

## Summary 
No mechanism to close the market.  

## Impact
Denial of service to closeMarket.

## Vulnerability Details 
 Only controller can call closeMarket but there is no implementation to close market in controller.

## Tools Used
Manual Review
## Recommended Mitigation Steps
Add a mechanism to close the market in controller.


## Assessed type

Other
DoS Any Market by Frontrunning Creation with a Codehash Change
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/WildcatMarketController.sol#L351


# Vulnerability details

## Impact
Any market contract can be DoSed by sending a 1 wei transaction to the market address that will be created for a user.

When an account has no code and has never been interacted with, the codehash will be bytes32(0).

This will result in market creation succeeding at this line https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/WildcatMarketController.sol#L351

However, when an account has had a transaction sent to it, the codehash changes to keccak256(“”) (c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470). The require statement then fails because codehash does not equal bytes32(0) and creation will be reverted despite no code being at that address.

This is a high impact because you can stop any market contracts from ever being created.

## Proof of Concept
contract CodehashTest {

   function notZeroCodeHash() external payable returns(bytes32 firstCodeHash, bytes32 secondCodeHash) {
   	// Random address that has had 0 interactions
   	firstCodeHash = address(0xc93356BdeAf3ceA6284A6Cc747fa52DD04AfB2A7).codehash;
   	payable(0xc93356BdeAf3ceA6284A6Cc747fa52DD04AfB2A7).transfer(1);
   	secondCodeHash = address(0xc93356BdeAf3ceA6284A6Cc747fa52DD04AfB2A7).codehash;
   }

}

## Tools Used
Manual

## Recommended Mitigation Steps
Add `&& != bytes32(c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470)` to the require.



## Assessed type

DoS
DoS Any Controller by Frontrunning Creation with a Codehash Change
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/WildcatMarketControllerFactory.sol#L294


# Vulnerability details

## Impact
Any controller contract can be DoSed by sending a 1 wei transaction to the controller address that will be created for a user.

When an account has no code and has never been interacted with, the codehash will be bytes32(0).

This will result in controller creation succeeding at this line https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/WildcatMarketControllerFactory.sol#L294

However, when an account has had a transaction sent to it, the codehash changes to keccak256(“”) (c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470). The require statement then fails because codehash does not equal bytes32(0) and creation will be reverted despite no code being at that address.

This is a high impact because you can stop any controller contracts from ever being created.

## Proof of Concept
contract CodehashTest {

   function notZeroCodeHash() external payable returns(bytes32 firstCodeHash, bytes32 secondCodeHash) {
   	// Random address that has had 0 interactions
   	firstCodeHash = address(0xc93356BdeAf3ceA6284A6Cc747fa52DD04AfB2A7).codehash;
   	payable(0xc93356BdeAf3ceA6284A6Cc747fa52DD04AfB2A7).transfer(1);
   	secondCodeHash = address(0xc93356BdeAf3ceA6284A6Cc747fa52DD04AfB2A7).codehash;
   }

}

## Tools Used
Manual

## Recommended Mitigation Steps
Add `&& != bytes32(c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470)` to the require.



## Assessed type

DoS
DoS Any Escrow by Frontrunning Creation with a Codehash Change
Audit: 2023-10-wildcat-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/WildcatSanctionsSentinel.sol#L106


# Vulnerability details

## Impact
Any escrow contract can be DoSed by sending a 1 wei transaction to the escrow address that will be created for a user.

When an account has no code and has never been interacted with, the codehash will be bytes32(0). 

This will result in escrow creation succeeding at this line https://github.com/code-423n4/2023-10-wildcat/blob/c5df665f0bc2ca5df6f06938d66494b11e7bdada/src/WildcatSanctionsSentinel.sol#L106

However, when an account has had a transaction sent to it, the codehash changes to keccak256(“”) (c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470). The require statement then fails because codehash does not equal bytes32(0) and creation will be reverted despite no code being at that address.

This is a high impact because you can stop any escrow contracts from ever being created.

## Proof of Concept
contract CodehashTest {

   function notZeroCodeHash() external payable returns(bytes32 firstCodeHash, bytes32 secondCodeHash) {
       // Random address that has had 0 interactions
       firstCodeHash = address(0xc93356BdeAf3ceA6284A6Cc747fa52DD04AfB2A7).codehash;
       payable(0xc93356BdeAf3ceA6284A6Cc747fa52DD04AfB2A7).transfer(1);
       secondCodeHash = address(0xc93356BdeAf3ceA6284A6Cc747fa52DD04AfB2A7).codehash;
   }

}

## Tools Used
Manual

## Recommended Mitigation Steps
Add `&& != bytes32(c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470)` to the require.



## Assessed type

DoS