Incorrect gas limit check

Lines of code Vulnerability details Summary The relayCalls function incorrectly checks the gas limit provided in the gasLimit parameter against the maxGasLimit variable instead of checking if it is less than or equal to the msg.gas value. Impact This bug allows the caller of relayCalls to specify...

Replay Attack possible by processCalls function

Lines of code Vulnerability details Impact Calls can be processed multiple times Proof of Concept The processCalls function uses the require function to check whether the nonce and calls values have been relayed, but it does not check whether the sender value is the same as the msg.sender value...

Possible DoS On executeCalls() function

Lines of code Vulnerability details Impact The contract can be in a state of DoS as the function executeCalls would consume all the gas as there is no upper limit on the number of calls that can be inside the array calls. Proof of Concept In the function here it perform a for loop and loops throu...

Incorrect behavior in CrossChainExecutorPolygon contract

Lines of code Vulnerability details Description: We have discovered an issue with the CrossChainExecutorPolygon contract. When a message with a nonce that has already been executed is received, the contract does not prevent the message from being processed or display an error message. This issue...

Incorrect _isAuthorized function logic

Lines of code Vulnerability details Summary The isAuthorized function in the CrossChainExecutorOptimism contract compares the message sender address to the address of the crossDomainMessenger contract, but it should be comparing the xDomainMessageSender value returned by the crossDomainMessenger...

CrossChainRelayerArbitrum.processCalls() can be invoked multiple times.

Lines of code Vulnerability details Impact In the CrossChainRelayerArbitrum contract once a Call has been relayed using the relayCalls function, processCalls can be invoked multiple times by anyone for the respective Call. Due to this redundant IInbox.createRetryableTicket calls are triggered and...

ExecutorAware doesn't adequately validate sender for nonce

Lines of code Vulnerability details Impact Contracts on the execution chain are asked to inherit from ExecutorAware.sol. This gives them the ability to check msgSender and nonce pulled from the calldata in the format encoded by the executor. While the msgSender function adequately checks that the...

Upgraded Q -> M from #400 [1670235895275]

Judge has assessed an item in Issue 400 as M risk. The relevant finding follows: L01 - EOA restriction of wallet representative can be bypassed A node operator can call registerBLSPublicKeys to register a node runner to LSD and create a new smart wallet. The protocol only allows EOAs to be...

ProcessedCalls Event Emission Vulnerability

Lines of code Vulnerability details Summary The contract is vulnerable to reentrancy attacks through the ProcessedCalls event. The event is emitted with the ticketId of the newly created retryable ticket, which can be used by an attacker to reenter the contract. Impact An attacker could exploit...

Nonce not properly checked in CrossChainExecutorArbitrum contract

Lines of code Vulnerability details Summary The CrossChainExecutorArbitrum contract does not properly check the nonce before executing calls. This allows a potential attacker to replay a batch of calls that have already been executed. Impact If a batch of calls is replayed, it could result in...

the executor can execute fake cross-chain function call

Lines of code Vulnerability details Impact The caller on relayer side can be rugged if the executor call the executeCall on execution side directly to use consume the nonce and fake cross-chain function call. Proof of Concept The expected behavior is that: the relayer relays a cross-chain request...

Upgraded Q -> M from #316 [1670230229509]

Judge has assessed an item in Issue 316 as M risk. The relevant finding follows: compound in AutoPxGmx can be called by anyone and can be sandwiched if a poorly chosen amountOutMinimum is used. The idea is to call the function often by adding an incentive to the caller. There is a problematic...

Upgraded Q -> M from #38 [1670234424045]

Judge has assessed an item in Issue 38 as M risk. The relevant finding follows: L2. Pool selection for the compound is not restricted Compound function of AutoPxGmx contract is public and available for everyone. An attacker can create a custom pool with a higher fee value currently, on tests it...

CrossChainExecutorPolygon does not implement the executeCalls function

Lines of code Vulnerability details Impact The CrossChainExecutor contracts in the codebase are meant to follow the CrossChainExecutor interface as defined in EIP-5164. Each L2 network specific CrossChainExecutor contract is also expected to inherit and follow the ICrossChainExecutor interface...

Integer Overflow

Lines of code Vulnerability details Impact Potential integer overflow vulnerability in the relayCalls function. The function does not check for the maximum value of the gasLimit parameter, and if it is set to a value greater than the maxGasLimit, it will cause an integer overflow. Integer overflo...

Upgraded Q -> M from #402 [1670185822442]

Judge has assessed an item in Issue 402 as M risk. The relevant finding follows: Staked Gmx RewardTracker may retain allowances Summary: Both the configureGmxState function and the setContractContracts c, address contractAddress can be used to update the PirexGmx contract's stakedGmx storage...

Potential reentrancy attack

Lines of code Vulnerability details Impact There is a potential of reentrancy attack in executeCalls in EthereumToArbitrumExecutor.sol since CallLib is making an external call with its executeCalls and we do not know the implementation of the contract that will be called eventually. The same issu...

DoS on relayCalls when the nonce variable reach type(uint256).max

Lines of code Vulnerability details Impact Denial of service on relayCalls functions when the nonce variable reach typeuint256.max Proof of Concept When the smart contracts start to be used, the variable in storage nonce will start to increment by 1, and since the nonce variable cannot be...

Fail to verify the result of a low level function call

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. It fails to check properly if the call is successful because: 1 It does not check the return data; 2 it does not check if the target address is a valid contract. A contract that has no code will still...

Upgraded Q -> M from #265 [1669939411439]

Judge has assessed an item in Issue 265 as M risk. The relevant finding follows: ETH not updated in internal accounting of giant pools Giant pools have a feature of bringing ETH back to the giant pools from the vaults. The received ETH in not updated in internal accounting and therefore cannot be...

Relayed calls in EthereumToArbitrumRelayer can be replayed

Lines of code Vulnerability details Impact A relayed call can be processed multiple times allowing somebody to execute the user's call multiple times. The bridge allows arbitrary calls to contracts. Depending on the nature of the call, this could result in a loss of funds for the user. Proof of...

[ZZ-004] During the deprecation period where both .eth registrar controllers are active, a crafted hack can be launched and cause the same malicious consequences of [ZZ-001] even if [ZZ-001] is properly fixed

Severity: High Status: Has not been reported Description, Specifically, according to the documentation, there will be a deprecation period that two types of .eth registrar controllers are active. Names can be registered as normal using the current .eth registrar controller. However, the new .eth...

[ZZ-001] PARENT_CANNOT_CONTROL and CANNOT_CREATE_SUBDOMAIN fuses can be bypassed

Severity: High Status: Has been reported to and comfirmed by Jeff ENS team Report Time: 11/28/2022 12:31 AM EST Description The fuse constraints can be violated by a malicious owner of the parent node i.e., the hacker. There are two specific consequences the hacker can cause. Suppose the subnode...

Reentranxcy in executeCalls()

Lines of code Vulnerability details Impact The contract first checks that the message sender is authorized and then marks the provided nonce as executed before calling the executeCalls function in CallLib. However, if CallLib.executeCalls calls back into this contract, the executeCalls function...

Upgraded Q -> M from #373 [1670018401792]

Judge has assessed an item in Issue 373 as M risk. The relevant finding follows: N2. ETH not accumulated in previewAccumulatedETH supposed to have accumulated += ... Although it is an external view function, depending on its usages, it may present more issues to the callers. --- The text was...

Upgraded Q -> M from #236 [1669938261828]

Judge has assessed an item in Issue 236 as M risk. The relevant finding follows: It is possible the DAO determine the amount of commission very high for its own benefit, so setting a range for determining the commission seems logical. Especially MAX commission should be pre- defined. --- The text...

Upgraded Q -> M from #205 [1669936745167]

Judge has assessed an item in Issue 205 as M risk. The relevant finding follows: L01 - No check if EOARepresentative or EOARepresentativeOfNodeRunner is an EOA or a smart contract Impact A smart contract can end up being assigned as a smartWalletRepresentative. Such smart contract might not have...

Upgraded Q -> M from #121 [1669815281189]

Judge has assessed an item in Issue 121 as M risk. The relevant finding follows: Require - always false contracts/liquid-staking/LiquidStakingManager.sol:280 isNodeRunnerWhitelistednodeRunner comparing to itself requireisNodeRunnerWhitelistednodeRunner != isNodeRunnerWhitelistednodeRunner,...

Upgraded Q -> M from #38 [1669737057849]

Judge has assessed an item in Issue 38 as M risk. The relevant finding follows: 6. require check will always be false!! the require check will always be false so it the function will not do what it was designed to do and it will always revert Unnecessary update to same status...

Upgraded Q -> M from #16 [1669734774225]

Judge has assessed an item in Issue 16 as M risk. The relevant finding follows: AQ6: This function provides too much power to Dao, if the dao calls the function, then he can be the node runner of each smart wallet and then call withdrawETHForKnot to drain each smart wallet. --- The text was updat...

Steal deposit fund in ERC4626 vault by exchange rate manipulation

Lines of code Vulnerability details Impact Although the PirexERC4626 and AutoPxGlp contract check for 0 shares, the rounding down error can still be used to steal new user deposit. Part of the new deposit could be stolen. The attacker may monitor the pool activities to catch the steal...

Incorrect rounding while withdrawing assets from AutoPxGmx and AutoPxGlp contracts

Lines of code Vulnerability details The function previewWithdraw is overridden in the AutoPxGmx and AutoPxGlp contracts to account for penalty fees while exiting the vaults. This happens in line 212 of the AutoPxGmx contract and similarly in line 190 of the AutoPxGlp contract: return totalSupply ...

isContract might return false for the contracts

Lines of code Vulnerability details Impact The Turnstile contract's register function assumes the msg.sender is a smart contract. The validation of this is carried out in eventhandler.go's ValidateContract function. ValidateContract checks whether the address has an emptyCodeHash which is zero...

user fund lose in deposit() of PirexERC4626 contract because A MALICIOUS EARLY USER/ATTACKER CAN MANIPULATE THE VAULT’S PRICEPERSHARE TO TAKE AN UNFAIR SHARE OF FUTURE USERS’ DEPOSITS

Lines of code Vulnerability details Impact This is a well-known attack vector for new contracts that utilize pricePerShare for accounting. Attacker can cause totalAssets / totalSupply ratio to go as high as he wants and then because of rounding error in convertToShares lower amount of share would...

Code is vulnerable to ERC4626 first depositor shares manipulation exploit

Lines of code Vulnerability details Proof of Concept The normal ERC4626 implementation which is not changed in the repository has a vulnerability which can result in the first depositor stealing every subsequent depositor’s funds. It works like this: 1. Vault is just deployed and Bob deposits jus...

MINTING OF NFT AT WILL

Lines of code Vulnerability details Impact register is an unrestricted public function where any new msg.sender is going to get through the modifier onlyUnregistered. With a non-zero recipient argument passed into the function, a new NFT is going to be minted to the recipient. Consequently, an...

The First Turnile Mint Token ID starts with 0.

Lines of code Vulnerability details Impact The First Turnile Mint Token ID starts with 0. Proof of Concept After deployment, the first Turnile token ID to be minted when a user calls the register function, is 0. At this point, the currentTokenId becomes 1 but the token doesn’t exist until the...

Deposit can be front-runned

Lines of code Vulnerability details Impact The depositor who got frontrun by the attacker will lose all their funds. And all the future depositors. An attacker can front run the first user's deposit and transfer tokens to the vault directly causing all future depositors to lose all their funds...

First depositor who is a whale account can deny later depositors who are smaller accounts from using AutoPxGmx contract, such as for depositing GMX for apxGMX

Lines of code Vulnerability details Impact A whale account that owns a lot of GMX can call the following PirexGmx.depositGmx function to deposit much GMX for pxGMX. As the first depositor for the AutoPxGmx contract, this account can then call the AutoPxGmx.depositGmx function to deposit 1 wei GMX...

Deposits and compounds will be frozen after a PirexGmx migration

Lines of code Vulnerability details Impact After a migration of the platform PirexGmx contract, the approval of the AutoPxGlp from the new PirexGmx contract will be zero. The same issue is here for the AutoPxGmx contract. Proof of Concept Even though the approval of gmxBaseReward formerly WETH fo...

[M2] It is possible to accidentally send ETH to an invalid token Id

Lines of code Vulnerability details Impact ​ ETH can be either loss or stolen PoC The function distributeFees is not checking if the tokenId is valid. That means that ETH can be sent to non-minted token. In case tokenId is a big number this ETH will be lost. If the id is not so big someone can mi...

The existence of the tokenID is not validated in distributeFees()

Lines of code Vulnerability details Impact Turnstile contract has distributeFees function which the Canto team/smart contract utilizes to distribute the fees to the tokenID's for the smart contract that is registered through register function. The existence of the tokenID's are checked both in...

incorrect commend and/or rounding issues in AutoPxGmx and AutoPxGlp

Lines of code Vulnerability details Impact The comments on the affected lines state previewWithdraw will round up. However, the implementation, an inner call to convertToShares is made, which actually calls mulDivDown. From further inspection, this pair of functions withdraw, previewWithdraw as...

Solmate saftransfer and safetransferfrom does not check the codesize of the token address, which may lead to fund loss

Lines of code Vulnerability details In PirexGmx.sol and ERC4626Vault.sol, the contract uses the solmate library which does not check the existence of code at the token address. This is a known issue when using solmate's libraries. Reference: Impact Possible loss of funds and miscalculation. Proof...

Existing tokens can be given to other contracts when assign function is called

Lines of code Vulnerability details Impact In the Turnstile contract when the assign function is called any unregistered contract can register himself as the feeRecipient for any given token id, but in reality only the token owner should be able to assign a new smart contract as feeRecipient for...

compound could be used by uniswap stakers to maximize fees for AutoPxGmx users

Lines of code Vulnerability details Impact Anyone can call AutoPxGmx::compound. Hence a staker in the 10000 1% fee uniswap pool can call compound with that pool and take a larger fee from AutoPxGmx users maximizing their gains and griefing users. Proof of Concept fee chooses which uniswap pool to...

Possible double spending issue for PirexERC4626 vault

Lines of code Vulnerability details Impact Solmate's ERC20 does not provide option to increase/decrease allowance, and only option to do so is by setting it via approve - which sets this amount directly. This poses a problem of double spending, when a user want to check current allowance, and bad...

First depositor can inflate share price

Lines of code Vulnerability details Impact A well-known vulnerability for ERC4626 vaults is the inflation of the share price on the first deposit. Because AutoPxGlp and AutoPxGmx use the balance of the underlying asset for totalAssets and do not have an initial minimum deposit amount, they are al...

Uint underflow issue

Lines of code Vulnerability details Impact Potential underflow if shares is greater than totalSupply Proof of Concept Tools Used Manual review Recommended Mitigation Steps Before the following line, check if totalSupply is greater or equal to shares --- The text was updated successfully, but thes...

distributeFees did not check if tokenId exist can lead to loss of asset

Lines of code Vulnerability details Impact distributeFees did not check if tokenId existed, can lead to loss of asset Proof of Concept inside Turnstile.sol file, the distributeFees function did not check if the tokenId exist or not. 148: function distributeFeesuint256 tokenId public onlyOwner...