Sanctionned funds keep earning APR, and protocol earning fees on these funds

Lines of code Vulnerability details Impact When a user is sanctioned, if he has a scaledBalance not in the withdrawal queue, calling the nukeFromOrbit function will send sanctioned funds to an escrow contract, and these funds will keep earning APR. This is because when a deposit is executed, the...

Swapped parameters when calling createEscrow()

Lines of code Vulnerability details Impact getEscrowAddress returns the wrong WildcatSanctionsEscrow. Borrower can steal lender's escrowed funds. Proof of concept createEscrow and getEscrowAddress both take the parameters borrower, account, asset, in that order, as defined in...

potential griefing attack on deployMarket

Lines of code 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...

InterestRate can be changed during close market.

Lines of code 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...

Deploying a market with a non-ERC20 asset can cause incorrect interaction with asset

Lines of code Vulnerability details Impact The market contract may expect certain ERC20 functions to be present and behave in a specific way. If the asset contract does not adhere to the ERC20 standard, the market may behave unexpectedly, resulting in incorrect token balances, pricing, or other...

Permanent DoS on Market Creation Failure

Lines of code Vulnerability details Impact Permanent DoS of creating a market if anything fails in the market constructor. Within a create2 call, instead of failing when a revert occurs in the constructor being run, it just returns address0. If this occurs within a market that's being created the...

Usury from simple mistake

Lines of code Vulnerability details Impact A borrower making a simple mistake might be forced to pay an extortionate interest rate for en extended period of time. Severity rating I was hovering between Medium and High on this one. Medium because it is based on a user mistake. On the other hand, t...

The approve function can be frontrun

Lines of code Vulnerability details Impact Bob steals tokens from Alice. Proof of Concept In the file WildcatMarketToken.sol there is an approve function: function approveaddress spender, uint256 amount external virtual nonReentrant returns bool approvemsg.sender, spender, amount; return true; th...

ERC20 tokens can be incorrectly burnt because of insufficient validation

Lines of code Vulnerability details Impact ERC20 tokens are incorrectly burnt. Proof of Concept In the file WildcatSanctionsEscrow.sol there is a constructor function: constructor sentinel = msg.sender; borrower, account, asset = WildcatSanctionsSentinelsentinel.tmpEscrowParams; Let's suppose thi...

TRANSFERING FUNDS TO YOURSELF INCREASES YOUR BALANCE

Lines of code Vulnerability details Impact If transferred to yourself, it will cause your balance to increase, thus growing the token balance infinitely. Proof of Concept File: src/market/WildcatMarketToken.sol 54: transferfrom, to, amount; 74: accountsfrom = fromAccount; 78: accountsto =...

Based on the functionality, if the releaseEscrow() function can be called by unauthorized entities, it can lead to potential misuse or unintended transfer of assets.

Lines of code Vulnerability details Impact The absence of access control on the releaseEscrow function presents a significant security risk. As it currently stands, any external actor or contract can invoke this function, which may result in the unintended release of escrowed funds. This opens up...

Uninitialized State Variables

Lines of code Vulnerability details Impact in The resetTmpMarketParameters function is an internal function, which means it can only be called from within the WildcatMarketController contract itself. If a child contract inherits from WildcatMarketController and calls resetTmpMarketParameters befo...

potential DOS cause of rounding up at rayMul and rayDiv

Lines of code Vulnerability details Impact In rayMul and rayDiv , there is always rounding up ,cause of that , there will be potential DOS Proof of Concept function normalizeAmount MarketState memory state, uint256 amount internal pure returns uint256 return amount.rayMulstate.scaleFactor; functi...

Lack of access control on overrideSanction(), any user can override sanctioned address

Lines of code Vulnerability details Impact Without proper access control, any address can call the overrideSanction function and override the sanction status of an account. This can potentially be exploited by malicious actors to bypass sanctions and carry out unauthorized actions, putting the...

closeMarket() can only be called by the market controller but the controller has no function to close a market.

Lines of code Vulnerability details Description Due to the restriction on the closeMarket function, only the controller is able to use it, but the controller contract has no way to call it. Impact Since the borrower becomes unable to close a market once it opened, it becomes a big issue as the...

Invalid asset address can result to malicious Market Address and loss of fund

Lines of code Vulnerability details Impact The computeMarketAddress function is used to calculate the address where a market contract for a specific asset would be deployed. If an invalid asset address is passed, it could potentially lead to a collision with a valid market contract address, causi...

Incorrect Order of Operations in nukeFromOrbit Function

Lines of code Vulnerability details Impact the nukeFromOrbit function, the nonReentrant modifier is correctly applied. This means that the function cannot be reentered while it is already being executed the problem is that The blockAccountstate, accountAddress function is called before...

Lender can cause unintended behavior for the borrower's transaction

Lines of code Vulnerability details This vulnerability comes in the form of when a borrower wants to remove a lender as a both deposit and withdraw and set them as a withdraw only, to avoid paying more interest on their funds in the market, this plan may not go as planned, based on the nature of...

No Create2 Contract Deployment Check can prevent a borrower from deploying contracts from a factory if deployment fails

Lines of code Vulnerability details Descripion When a contract is deployed using Create2 the deployment can fail without causing a revert. The following conditions can cause it to not revert: 1. A contract already exists at the destination address. 2. Insufficient value to transfer. 3. Sub contex...

Borrower cannot change market capacity (max total supply) after creating a market

Lines of code Vulnerability details Impact As per docs, "Subsequent to launch, base APR and capacities can be adjusted by the borrower at will". After creating a market, a borrower cannot increase the maximum total supply which contradicts the documentation. Proof of Concept The...

Interest accumulation linked to state updates may leak value

Lines of code Vulnerability details Impact The protocol compounds interest on every call that updates the state. This is an intentional design choice. However, this does mean that the total return for the lender, and, conversely, the cost of debt for the borrower, can be influenced by the frequen...

DoS Any Escrow by Frontrunning Creation with a Codehash Change

Lines of code 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 bytes320. This will result in escrow creation...

Sanction Bypass Through Transferring to another account

Lines of code 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...

Sanction Bypass Through Depositing to Authorized Borrower's Market

Lines of code 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...

_blockAccount doesn’t transfer asset correctly getting portion of funds locked permanently

Lines of code 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...

DoS Any Market by Frontrunning Creation with a Codehash Change

Lines of code 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 bytes320. This will result in market creation...

wrong implementation of rayDiv.

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. 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 Recommended Mitigation Steps function...

safeTransferFrom Does Not Check for Code at the Token Address

Lines of code Vulnerability details Impact The solady safeTransferFrom does not check for code at a token address before transferring. This can result in a deposit being made in a selfdestructed token or an embryonic token such as one that can be created from another chain's bridge without the us...

Updating safeManager reference in Vault721 will brick transfer of safes

Lines of code Vulnerability details Impact Updating safeManager reference in Vault721 will brick safe transfers since the state of the new ODSafeManager instance won't have corresponding data. In addition, it is not clear how it would be possible to achieve seamless migration as particular...

M-05 Unmitigated

Lines of code Vulnerability details Mitigation of M-05: Issue NOT mitigated Mitigated issue M-05: Reward sandwiching in VotiumStrategy The issue was that exposure to the benefits of the VotiumStrategy might be unfairly time-weighted. There were two aspects mentioned: voting power and rewards. I d...

[H-02] Mitigation error: Null Votium withdrawal requests are queued last

Lines of code Vulnerability details Description When a request to withdraw is placed such that VotiumStrategy.requestWithdraw0 is called, this queues it to the end of all previous withdrawal requests as if an infinitesimal amount is to be withdrawn, incurring an artificially prolonged withdrawal...

During Safe Transfer, the Receiving User Loses Control of the Safe, Resulting in the Safe Being Lost

Lines of code Vulnerability details Impact Assuming a user wants to transfer their safe NFT to another user, post transfer Vault721::afterTokenTransfer is triggered. This function in turn calls the IODSafeManager::transferSAFEOwnership function to complete the transfer. The problem here is, that...

[ADRIRO-NEW-M-02] AfEth withdrawals are delayed even if the vAfEth withdrawal amount is zero

Lines of code Vulnerability details Summary While zero amount withdrawals of SafEth have been prevented, the updated codebase still executes the withdrawal process for zero amount withdrawals of vAfEth, creating an unnecessary delay in AfEth withdrawals. Impact In AfEth, the withdrawal process is...

AccountingEngine can only transfer a maximum of 1% of the surplus to the designated extraSurplusReceiver

Lines of code Vulnerability details Impact The impact of this vulnerability is related to the validation of the surplus transfer percentage in the AccountingEngine contract. The vulnerability arises from an incorrect validation check that restricts the surplus transfer percentage to WAD 1%. Proof...

[ADRIRO-NEW-M-05] Rewarder should not be allowed to apply rewards on CVX tokens

Lines of code Vulnerability details Summary The rewarder role should not be allowed to modify the balance of CVX tokens when applying rewards, otherwise the internal CVX balance tracking could get out of sync with major consequences for the protocol. Impact The introduction of internal CVX balanc...

TWAP can lead to loss of manipulation of price

Lines of code Vulnerability details Impact There are tradeoffs when choosing the length of the period of time to calculate a TWAP. Longer periods are better to protect against price manipulation, but come at the expense of a slower, and potentially less accurate, price. Proof of Concept Both the...

surplusTransferPercentage will always be less than 1%

Lines of code Vulnerability details Impact The protocol has a feature to auction the surplus amount and send some % out of that to extraSurplusReceiver but currently this % always less than 1% which limits the amount extraSurplusReceiver can get out of the surplus Proof of Concept we believe this...

When Creating a Safe Via ODSafeManager::openSAFE, the User Proxy Is Wrongly Set As the Safe Owner

Lines of code Vulnerability details Impact We can observe from Vault721::mint function that the input usr in ODSafeManager::openSAFE function needs to be a previously built proxy of the user address. function mintaddress proxy, uint256 safeId external requiremsg.sender == addresssafeManager, 'V72...

Upgraded Q -> 2 from #272 [1698254247989]

Judge has assessed an item in Issue 272 as 2 risk. The relevant finding follows: ERC1155 can be inflated if the token doesn’t revert on failed transfer --- The text was updated successfully, but these errors were encountered: All reactions...

use of correct modifier

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. 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 Recommended Mitigation Steps function...

[ADRIRO-NEW-H-02] Users loses their share of rewards while waiting for withdrawal

Lines of code Vulnerability details Summary Withdrawals in AfEth undergo a delay until the underlying CVX tokens can be withdrawn. Depositors need to request a withdrawal and wait until the required withdrawal epoch before making their withdrawal effective. During this period of time, they will...

On repaying and taking collateral there is 2 times modifying tokenCollateral[cType][account/sourse]this lead to a problem

Lines of code Vulnerability details Impact when you are repaying your tokenCollateralcTypeaccount is modified 2 times, which leads to incorrect data Proof of Concept On calling repayAllDebtAndFreeTokenCollateral or repayDebtAndFreeTokenCollateral first you are calling modifySAFECollateralization...

Wrong accounting used in auctionDebt in AccountingEngine contract

Lines of code Vulnerability details Impact As the title suggests, the accounting in auctionDebt function is incorrect. In this particular section of the code: uint256 coinBalance = safeEngine.coinBalanceaddressthis; uint256 debtBalance = safeEngine.debtBalanceaddressthis; if...

Introduce minEpoch to prevent withdrawal requests being front-runned

Lines of code Vulnerability details Original Issue M-04: VotiumStrategy withdrawal queue fails to consider available unlocked tokens causing different issues in the withdraw process Issue Details The issue raised above occured whenever there was an unlocked balance which could be used to fulfill...

Scaling Issue in AccountingEngine.auctionSurplus Causing Token Drains

Lines of code Vulnerability details Impact The impact of this vulnerability is significant as it leads to a scaling problem in surplus auctions conducted by the AccountingEngine. The vulnerability arises from the way the amountToSell in surplusAuctionHouse.startAuction call and rad in...

Wrong WAD calculation in AccountingEngine contract leading to start auction with selling amount minimum 100 time bigger than expected

Lines of code Vulnerability details Impact In the Math library, 1 WAD is equal to 1e18 which is assumed 1 For example: wmul2e18, 4e18 = 8e18 In AccountingEngine contract, the devs assumed that 1 WAD is equal to 0.01 1%, 100 WAD is equal to 1 100%. Hence, the function auctionSurplus will make star...

correct use of safeAllowed modifier

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. 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 Recommended Mitigation Steps function...

Price inflation by locking CVX on behalf of VotiumStrategy

Lines of code Vulnerability details Impact The price of vAfEth can be inflated with severe rounding errors as a result. Proof of Concept In VotiumStrategy the price of vAfEth is calculated by function cvxInSystem public view returns uint256 uint256 total = ILockedCvxVLCVXADDRESS.lockedBalanceOf...

repayAllDebt joins system tokens to the proxy not to the Safe contract

Lines of code Vulnerability details Impact repayAllDebt now calls joinSystemCoins with dest = addressthis, which in case a proxy makes a delegated call to this function will cause the user's tokens to be transferred to its proxy, then in CoinJoin.join it will transfer internal coins from CoinJoin...

Broken logical expression in onlyManager()

Lines of code Vulnerability details Original Issue H-05: Functions in the VotiumStrategy contract are susceptible to sandwich attacks Details Depositing/withdrawing directly to/from derivatives provides an opportunity for an adversary to sandwich the users, since the slippage control mechanism wa...