Anyone can remove feeders from NFTFloorOracle.

Lines of code Vulnerability details Impact There is no onlyRole modifier in removeFeeder, so anyone can remove feeders from NFTFloorOracle, and it will cause a DOS attack. Proof of Concept function removeFeederaddress feeder external onlyWhenFeederExistedfeeder //@audit no modifier...

Oracle does not treat upward and downward price movement the same in validity checks, causing safety issues in oracle usage.

Lines of code Vulnerability details Description NFTFloorOracle retrieves ERC721 prices for ParaSpace. maxPriceDeviation is a configurable parameter, which limits the change percentage from current price to a new feed update. We can see how priceDeviation is calculated and compared to...

Anyone can prevent themselves from being liquidated as long as they hold one of the supported NFTs

Lines of code Vulnerability details Contrary to what the function comments say, removeFeeder is able to be called by anyone, not just the owner. By removing all feeders i.e. floor twap price oracle keepers, a malicious user can cause all queries for the price of NFTs reliant on the NFTFloorOracle...

suppliers funds loss because attacker can transfer his collateralized tokens when health factor is below liquidation threshold by reentrancy attack during executeLiquidateERC20() logic and transferring collateralize

Lines of code Vulnerability details Impact Function executeLiquidateERC20 is for liquidating a position if its Health Factor drops below 1. The caller liquidator covers liquidationAmount amount of debt of the user getting liquidated, and receives a proportional amount of the collateralAsset plus ...

Attacker can manipulate low TVL Uniswap V3 pool to borrow and swap to make Lending Pool in loss.

Lines of code Vulnerability details Impact In Paraspace protocol, any Uniswap V3 position that are consist of ERC20 tokens that Paraspace support can be used as collateral to borrow funds from Paraspace pool. The value of the Uniswap V3 position will be sum of value of ERC20 tokens in it. functio...

Buy can be executed after sale end

Lines of code Vulnerability details Impact In LPDA.sol buy function when all tokens are minted, the final price is set and the ether from the sale and fee is sent to the saleReceiver and feeReceiver addresses. Since there is no check to validate if sale has ended the function can be executed with...

Wrong logic in function _removeFeeder() cause feeders unable to be removed.

Lines of code Vulnerability details Impact In NFTFloorPrice, there are multiple components to allow easy adding/removing keepers address public feeders - List of all keepers' address mappingaddress = FeederPositionindex, register private feederPositionMap When adding new keeper, new keeper addres...

Malicious feeReceiver or saleReceiver can steal the user's refund ETH by calling the buy function multiple times in LPDA

Lines of code Vulnerability details Impact In the LPDA contract, the fee is transfered to feeReceiver and the totalSale to saleReceiver when newId == temp.finalId, meaning that the amount of tokens that were minted has been reached. However, the call to the internal end function only emits an eve...

Implementation can be self destruct by deployer, effectively break all running sale and lock all assets.

Lines of code Vulnerability details Impact Sale in Escher is deployed using minimal proxy pattern, where there is only 1 implementation contract is deployed to save deployment gas. Also, in Open Edition and FixedPrice sale, when sale is not started yet, owner can cancel it, self destruct the prox...

LPDA sales can potentially have buying function reverting indefinately due to negative price

Lines of code Vulnerability details Impact While i'm assuming there are checks for this on UI or off-chain, this wasn't mentioned in the docs or the comments, so its worth flagging and possibly implementating the mitigation step as a precaution since it is also cheap on gas. The price can...

Use of payable.transfer() may lock user funds

Lines of code Vulnerability details Impact The use of payable.transfer is heavily frowned upon because it can lead to the locking of funds. The transfer call requires that the recipient has a payable callback, only provides 2300 gas for its operation. This means the following cases can cause the...

NFTFloorOracle price feeders can be removed by anyone

Lines of code Vulnerability details Impact The nfts price feeders in the NFTFloorOracle contract should be added or removed only by the admin but because the removeFeeder function is missing the onlyRoleDEFAULTADMINROLE modifier any user can remove a feeder, this could impact the whole protocol i...

Oracle will become invalid much faster than intended on non-mainnet chains

Lines of code Vulnerability details Description NFTFloorOracle is in charge of answering price queries for ERC721 assets. EXPIRATIONPERIOD constant is the max amount of blocks allowed to have passed for the reading to be considered up to date: uint256 diffBlock = currentBlock - priceInfo.updatedA...

The LPDA will fail, because the Arithmetic underflow

Lines of code Vulnerability details Impact The LPDA will fail to buy mint new NFTs even if block.timestamp = temp.startTime , block.timestamp = temp.endTime and newId sale.dropPerSecond sale.endTime - sale.startTime, "INVALID DROP PER SECOND"; --- The text was updated successfully, but th...

LPDA.sol and FixedPrice.sol will lock the funds forever

Lines of code Vulnerability details Impact Possibility of IDs collision The ether will be locked on FixedPrice or LPDA Proof of Concept On the same Escher721 Let’s say the first collection start from id = 0 and end on id = 10 So the next collection of the same Escher721 We can say the next part o...

NFTFloorOracle's asset and feeder structures can be corrupted

Lines of code Vulnerability details NFTFloorOracle's addAsset and addFeeder truncate the assets and feeders arrays indices to 255, both using uint8 index field in the corresponding structures and performing uint8assets.length - 1 truncation on the new element addition. 2^8 - 1 looks to be too tig...

Discrepency in the Uniswap V3 position price calculation because of decimals

Lines of code Vulnerability details Impact When the squared root of the Uniswap V3 position is calculated from the getOracleData function, the price may return a very high number in the case that the token1 decimals are strictly superior to the token0 decimals. See: The reason is that at the...

THE FUNCTION LOGIC OF _REMOVEFEEDER() IS FLAWED

Lines of code Vulnerability details Impact When the admin calls removeFeeder, it will internally call removeFeeder that will have the feeder removed from feeders before getting its UPDATEROLE revoked. In the midst of doing this, the protocol forgets to update index of feederPositionMap belonging ...

LAST PRICE DUTCH AUCTION SALE (LPDA) CAN BE EXPLOITED

Lines of code Vulnerability details Impact The function logic of buy in LPDA.sol can be exploited by shrewd buyers to achieve the lowest finalPrice possible. Proof of Concept LPDA.solL58-L89 function buyuint256 amount external payable uint48 amount = uint48amount; Sale memory temp = sale;...

Downcast can lead to overflow and impact the functionality to remove an asset in NFTFloorOracle

Lines of code Vulnerability details Impact When adding a new asset, the index for the last asset will be saved and downcasted on L284. If the number of assets is bigger than 256, the downcasting operation will lead to a silent overflow. Consequentially, the incorrect index will be stored. This ca...

Pausing assets only affects future price updates, not previous malicious updates.

Lines of code Vulnerability details Description NFTFloorOracle retrieves ERC721 prices for ParaSpace. It is pausable by admin on a per asset level using setPauseasset, flag. setPrice will not be callable when asset is paused: function setPriceaddress asset, uint256 twap public onlyRoleUPDATERROLE...

Anyone can call addLiquidity function and be the router

Lines of code Vulnerability details Impact Anyone can call addLiquidity, meaning that when IAddLiquidityCallbackmsg.sender.addLiquidityCallbacktokenAAmount, tokenBAmount, data; is called, the msg.sender can be a contract that a malicious user has deployed and has a addLiquidityCallbacktokenAAmoun...

Actor can send an arbitrary token when adding liquidity

Lines of code Vulnerability details Impact Anyone can call addLiquidity directly and can input tokenId, params and data. The data inputs are never checked, so the user can send anything in there. Since the erc20 tokens routed are defined in the data parameter, user could send any token. Since the...

Actor can input malicious data in the swap function inputs

Lines of code Vulnerability details Impact Function swap has a data input parameter, which can be defined by the caller. Any user could therefore define a token address that they will send. By doing so user could create their own token and send it instead of tokenA and receive tokenB for free. By...

Upgraded Q -> M from #508 [1670444214372]

Judge has assessed an item in Issue 508 as M risk. The relevant finding follows: 508 --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded Q -> M from #454 [1670445333683]

Judge has assessed an item in Issue 454 as M risk. The relevant finding follows: L‑01 Don't use payable.transfer/payable.send The use of payable.transfer is heavily frowned upon because it can lead to the locking of funds. The transfer call requires that the recipient is either an EOA account, or...

Upgraded Q -> H from #439 [1670433195074]

Judge has assessed an item in Issue 439 as H risk. The relevant finding follows: L02 - close should not be able to close a specific id credit line As per the docs: Can a Borrower chose to repay any debt in any order? No. The app automatically selects which credit line can be repaid using a...

Payable functions do not refund excess and locks in

Lines of code Vulnerability details Impact All payable functions addCredit, increaseCredit, depositAndClose, depositAndRepay, closehttps://github.com/debtdao/Line-of-Credit/blob/698...

Upgraded Q -> M from #366 [1670366212013]

Judge has assessed an item in Issue 366 as M risk. The relevant finding follows: 1. Not support fee-on-transfer tokens Every tokens of credit line will be transferred from lender to LineOfCredit first, then to borrower later. These 2-transfer steps will make the tax for some fee-on-transfer token...

Upgraded Q -> M from #76 [1670347574630]

Judge has assessed an item in Issue 76 as M risk. The relevant finding follows: L02 address.callvalue:x should be used instead of payable.transfer Impact The use of payable.transfer is heavily frowned upon because it can lead to the locking of funds. The transfer call requires that the recipient...

Upgraded Q -> M from #35 [1670345543949]

Judge has assessed an item in Issue 35 as M risk. The relevant finding follows: No. 2 Any smart contract that uses transfer or send is taking a hard dependency on gas costs by forwarding a fixed amount of gas: 2300. If gas costs are subject to change, then smart contracts can’t depend on any...

Upgraded Q -> M from #366 [1670366311052]

Judge has assessed an item in Issue 366 as M risk. The relevant finding follows: 5. Cannot cancel mutual consent Mutual consent works by using two TXs with the same msg.data. However, when first one call, there is no way to cancel it. First caller might send wrong msg.data or later caller change...

Current implementation may be vulnerable to griefing attacks

Lines of code Vulnerability details Impact EIP 5164 states that: CrossChainExecutors SHOULD revert with a CallFailure error if a call fails. The current implementation of EIP-5164 makes the assumption CallLib.solL61-L72 that all call data are legitimately crafted. For context-agnostic protocols,...

Upgraded Q -> M from #400 [1670236164031]

Judge has assessed an item in Issue 400 as M risk. The relevant finding follows: L04 - LiquidStakingManager.dao can rug node operators with executeAsSmartWallet daoCommissionPercentage is used to calculate the portion of node operator network rewards that are sent to dao, when a node runner is...

CrossChainRelayerArbitrum contract gas limit bug

Lines of code Vulnerability details Summary The CrossChainRelayerArbitrum contract uses the maxSubmissionCost parameter to determine if the gasLimit provided to the processCalls function is greater than the maxGasLimit. This is incorrect because maxSubmissionCost should not be used to determine t...

setRelayer function not checking for null relayer address

Lines of code Vulnerability details Summary When calling the setRelayer function with a null relayer address, the function does not check for this and allows the address to be set. This issue can cause the contract to fail when calling the executeCalls function and potentially cause loss of funds...

Upgraded Q -> M from #400 [1670236078897]

Judge has assessed an item in Issue 400 as M risk. The relevant finding follows: L03 - LiquidStakingManager.dao can rug node operators with executeAsSmartWallet 202: function executeAsSmartWallet 203: address nodeRunner, 204: address to, 205: bytes calldata data, 206: uint256 value 207: external...

Potential security issues in CallLib solidity library

Lines of code Vulnerability details Description: The CallLib solidity library contains several potential security issues that could be exploited by attackers. Issue 1: The executeCalls function does not check if the sender parameter is the contract owner before allowing the calls to be executed...

ProcessedCalls event missing transaction hash

Lines of code Vulnerability details Summary The CrossChainRelayerArbitrum contract is missing the txHash parameter in the ProcessedCalls event. Impact The txHash is used to identify the transaction that was processed. Without this parameter, it will be impossible to know which transaction was...

Incorrect use of AddressAliasHelper.applyL1ToL2Alias() in _isAuthorized()

Lines of code Vulnerability details Summary In the isAuthorized function, the require statement checks if the msg.sender is equal to the result of calling AddressAliasHelper.applyL1ToL2Alias with relayer as the argument. However, this is incorrect, as AddressAliasHelper.applyL1ToL2Alias is intend...

Missing msg.value when executing the cross-chain request

Lines of code Vulnerability details Impact the cross-chain request will not support smart contract that requires ETH payment in destination chain on execution side. Proof of Concept When a user relayers call and performs a cross-chain request, the executor needs to execute the request in the...

relayCalls won't work for expensive operations

Lines of code Vulnerability details relayCalls won't work for expensive operations Vulnerability Details With maxGasLimit assigned to more than typeuint32.max and relayCalls being called with gasLimit equal or greater than typeuint32.max + 1, it will revert because of the overflow at casting. Thi...

Potential security issues in CrossChainExecutorOptimism contract

Lines of code Vulnerability details Title: Potential security issues in CrossChainExecutorOptimism contract Product: CrossChainExecutorOptimism contract Version: 0.8.16 Summary: The CrossChainExecutorOptimism contract contains several potential security issues that could allow unauthorized or...

Upgraded Q -> M from #251 [1670231833702]

Judge has assessed an item in Issue 251 as M risk. The relevant finding follows: AutoPxGlp.setPlatform and AutoPxGmx.setPlatform break the vaults functionalities. Looking at AutoPxGlp.setPlatform: this admin setter allows the owner to change the pirexGmx address in AutoPxGlp. The issue is that it...

Relayer/executor-already-set Error in CrossChainRelayerArbitrum Contract

Lines of code Vulnerability details Summary The setExecutor function in the CrossChainRelayerArbitrum contract improperly reverts when the executor variable has already been set. Impact This bug could prevent the CrossChainRelayerArbitrum contract from properly setting the executor variable,...

CrossChainExecutor contracts do not update the necessary states for failing transactions.

Lines of code Vulnerability details Impact The CrossChainExecutorArbitrum and CrossChainExecutorOptimism contracts both use CallLib library to invoke Calls on external contract. As per the CallLib library implementation, any failing Call results in the entire transaction getting reverted. The...

Cross-chain request does not have expiration time

Lines of code Vulnerability details Impact Cross-chain request does not have expiration time Proof of Concept In the current implementation, a caller in source chain can perform a relayer call to starts a cross-chain request. But it is not clearly when the executor will be executing the...

Funds may be lost if processCalls is called from a contract

Lines of code Vulnerability details Impact In CrossChainRelayerArbitrum.processCalls, msg.sender is set as the address to receive any refund both excess fee refund and call value refund in the createRetryableTicket call. Arbitrium credits the refunded value to L2 balance, so if the user doesn't...

CrossChainRelayerArbitrum contract: GasLimitTooHigh revert error not caught

Lines of code Vulnerability details Summary The relayCalls function in the CrossChainRelayerArbitrum contract reverts when the gasLimit parameter is greater than the maxGasLimit, but it does not have a catch block to handle the error. As a result, the transaction will fail without providing any...

Relayer/executor-already-set Revert in setExecutor()

Lines of code Vulnerability details Summary The setExecutor function reverts if the executor variable has already been set. Impact If the executor variable has already been set and setExecutor is called again, the transaction will fail and any gas spent on the transaction will be lost...