The tier setting parameter are unsafely downcasted from type uint256 to type uint80 / uint48 / uint40 / uint16

Lines of code Vulnerability details Impact The tier setting parameter are unsafely downcasted from uint256 to uint80 / uint48 / uint16 the tier is setted by owner is crucial because the parameter affect how nft is minted. the the callstack is JBTiered721Delegate.solinitialize - StorerecordAddTier...

Missing modifier allow infinite mint for tier

Lines of code Vulnerability details Impact It seems mintReservesFor function is missing the onlyOwner modifier which means Attacker can call this function to mint any amount of reserved tokens Proof of Concept 1. Observe the mintReservesFor function function...

User can mint more NFT than initial supply because of improper check of _storedTier.remainingQuantity in /JBTiered721DelegateStore#recordMint

Lines of code Vulnerability details Impact User can mint more NFT initial supply because of inproper check of storedTier.remainingQuantity For example, the owner can set the initial amount to 3, but 6 NFT can be minted. when the mintFor is called, the function calls JBTiered721DelegateStore.sol t...

Initialize: No access control for initializatino and possible multiple initializations

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. First of all, there is no modifier for access control, any one can call initialize and the two require statements won't provent it. Second, it is possible that the initialize function is called multiple...

The beneficiary could be the zero address

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. There is no zero address check for the beneficiary ,therefore it is possible the beneficiary is zero and we lose all the reserves Proof of Concept Provide direct links to all referenced code in GitHub...

Upgraded Q -> M from 345 [1665830444380]

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

Upgraded Q -> M from 220 [1665830289014]

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

Upgraded Q -> M from 221 [1665738683985]

Judge has assessed an item in Issue 221 as Medium 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 accoun...

Upgraded Q -> M from 160 [1665775526819]

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

Upgraded Q -> M from 211 [1665775603120]

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

Upgraded Q -> M from 269 [1665775697646]

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

outboundTransfer should return excess msg.value

Lines of code Vulnerability details Impact In function outboundTransfer, if users sends more msg.value than required, by accident, then the remaining msg.value is not sent back. So, if msg.value amount argument, then the excess msg.value is not sent back to msg.sender. This causes loss of funds f...

transferfrom with arbitrary from address allows attackers to receive tokens in L2 without paying

Lines of code Vulnerability details Impact In , the line token.transferFromfrom, escrow, amount; use an arbitrary from address. So an attacker can deposit victim's GTR token on L1, by using from address as victim's address, and receive equivalent tokens on L2 on attacker address. Proof of Concept...

Signature malleability not protected against

Lines of code Vulnerability details Vulnerability details OpenZeppelin has a vulnerability in versions lower than 4.7.3, which can be exploited by an attacker. The project uses a vulnerable version ECDSA signature malleability package.jsonL27-L28 package.jsonL27-L28 : "@openzeppelin/contracts":...

# ERC20 transfer / transferFrom with not checked return value

Lines of code Vulnerability details ERC20 transferFrom with not checked return value Impact Not every ERC20 token follows OpenZeppelin's recommendation. It's possible inside ERC20 standard that a transferFrom doesn't revert upon failure but returns false. Proof of Concept ERC20 transferFrom...

After proposed 0.8.0 upgrade kicks in, L2 finalizeInboundTransfer might not work.

Lines of code Vulnerability details Description L2GraphTokenGateway uses the onlyL1Counterpart modifier to make sure finalizeInboundTransfer is only called from L1GraphTokenGateway. Its implementation is: modifier onlyL1Counterpart require msg.sender ==...

No check for zero address

Lines of code Vulnerability details Impact No check for zero address Proof of Concept Tools Used Recommended Mitigation Steps Add check for zero address for contractAddress inside there is not need to emit event if contract does not exist. --- The text was updated successfully, but these errors...

Using ifAdmin modifier to forcefully interact with implementation contracts via _fallback() call.

Lines of code Vulnerability details Impact The modifier ifAdmin allows internal delegation to the implementation contract if caller is not admin by calling the fallback function which delegates the current call to implementation. This allows a user who is not admin to call to make a transaction...

User can send an excess of ETH to L1GraphTokenGateway

Lines of code Vulnerability details Impact User can send too much ether into the contract which may get stuck if there is issues with the refund process. Proof of Concept User sends too much ether to outboundTransfer. This is sent to a refund address in Arbitrum. If Arbitrum is compromised or suc...

No check transferFrom() return value

Lines of code Vulnerability details Impact The smart contract doesn’t check the return value of token.transferFrom, some erc20 token might not revert in case of error but return false. Proof of Concept as seen in several contests, for ex: Tools Used Visual inspection Recommended Mitigation Steps...

Signature can be reused across forks due to lack of chainid validation

Lines of code Vulnerability details Impact The signature for GraphTokenUpgradeable.permit won't be resilient to chainsplits. In the event of a chain fork, the message will be assumed valid of both chains and this could allow replays attacks across forks. Proof of Concept The chainid for the...

If L1GraphTokenGateway's outboundTransfer is called by a contract, the entire msg.value is blackholed, whether the ticket got redeemed or not.

Lines of code Vulnerability details The outboundTransfer function in L1GraphTokenGateway is used to transfer user's Graph tokens to L2. To do that it eventually calls the standard Arbitrum Inbox's createRetryableTicket. The issue is that it passes caller's address in the submissionRefundAddress a...

Set admin emit event with wrong data

Lines of code Vulnerability details Impact emit AdminUpdatedadmin, newAdmin; will emit AdminUpdated with same values. Proof of Concept Tools Used Code analytics Recommended Mitigation Steps store address of admin before --- The text was updated successfully, but these errors were encountered: All...

[NAZ-M3] Use safeTransfer()/safeTransferFrom() instead of transfer()/transferFrom()

Lines of code Vulnerability details Impact It is a good idea to add a require statement that checks the return value of ERC20 token transfers or to use something like OpenZeppelin’s safeTransfer/safeTransferFrom unless one is sure the given token reverts in case of a failure. Failure to do so wil...

Permanent lockup of tokens without recovery possible

Lines of code Vulnerability details Impact The callhook for whitelisted contracts adds an additional layer of complexity that can have multiple points of failure. If the execution of L2GraphTokenGateway.finalizeInboundTransfer fails indefinitely, there is currently no way to recover the...

No withdraw mechanism for eth sent to GraphProxy contract

Lines of code Vulnerability details Impact The GraphProxy contract implements receive and fallback functions to receive funds. However, there is no method associated with a user to withdraw his funds which might be sent accidentally to the proxy contract, thus leading to most of the eth locked in...

Atomicity Literally NOT Guaranteed

Lines of code Vulnerability details Impact According to the Arbitrum documentation, "... Cross chain and cross shard interoperability is a hard problem, ... It's important to differentiate between calls from Ethereum to Arbitrum and calls from Arbitrum to Ethereum. Ethereum contracts can send...

Missing 0 check can lead to unexpected behaviors

Lines of code Vulnerability details Missing checks for address0x0 on setters can lead to problems Impact User roles can being set to wrong values that block functionalities Summary Zero address should be checked for state variables, immutable variables. A zero address can lead into problems. Gith...

[NAZ-M2] MINTER_ROLE Can Be Granted By The Deployer and Can Mint Arbitrary Amount of Tokens

Lines of code Vulnerability details Impact If the private key of the deployer or an address with the MINTER is compromised, the attacker will be able to mint an unlimited amount of tokens. I believe this is unnecessary and poses a serious centralization risk. Tools Used Manual Review Recommended...

[NAZ-M1] GraphTokenUpgradeable.permit() Should Always Check recoveredAddress != 0

Lines of code Vulnerability details Impact The GraphTokenUpgradeable.permit function ignores the recoveredAddress != 0 check if isApprovedForAllownerrecoveredAddress is true. If a user accidentally set the zero address as the operator, tokens can be stolen by anyone as a wrong signature yield...

Transferfrom must return a bool

Lines of code Vulnerability details Impact Unhandled return values of transfer and transferFrom: ERC20 implementations are not always consistent. Some implementations of transfer and transferFrom could return ‘false’ on failure instead of reverting. It is safer to wrap such calls into require...

Use OpenZeppelin's safeTransferFrom instead of transferFrom when transferring ERC20 tokens

Lines of code Vulnerability details Impact In this case, since GRT token is used, the current implementation of GRT does have a return value for transferFrom and reverts on failure, but the same cannot be said for many other ERC20 tokens in the wild. OpenZeppelin recommends to always use...

Dont check return type

Lines of code Vulnerability details Impact Dont check return type Proof of Concept Tools Used Static analytics Recommended Mitigation Steps Add suitable checks --- The text was updated successfully, but these errors were encountered: 👎 1 trust1995 reacted with thumbs down emoji All reactions 👎 1...

Using ifAdminOrPendingImpl modifier to forcefully interact with implementation contracts via _fallback() call.

Lines of code Vulnerability details Impact The modifier ifAdminOrPendingImpl allows internal delegation to the implementation contract if caller is not admin by calling the fallback function which delegates the current call to implementation. This allows a user who is not admin to call to make a...

Cached EIP-712 domain separator may lead to replay attacks

Lines of code Vulnerability details Impact The usage of a cached DOMAINSEPARATOR present in the initializer of the GraphTokenUpgradeable contract may lead to replay attacks in the case of an eventual fork of the chain, since the cached domain separator is constructed with an initial chainId that...

Governor can rug all GRT by setting the gateway to her wallet (Governor may be hacked)

Lines of code Vulnerability details Impact Governor can rug all GRT by setting the gateway to her wallet Governor may be hacked. Proof of Concept First, the Governor set the gateway contract to her wallet function setGatewayaddress gw external onlyGovernor requiregw != address0, "INVALIDGATEWAY";...

Compromised Arbitrum: No Sanity/Security Checks on Amount in finalizeInboundTransfer() on Layer 2

Lines of code Vulnerability details Description / Proof of Concept If L2GraphTokenGateway.finalizeInboundTransfer receives a valid transaction from the bridge, it will immediately mint any amount of GRT tokens on Arbitrum. Impact This exposes an unnecessarily large attack surface as any compromis...

Set admin without accept method

Lines of code Vulnerability details Impact Set admin without method for accept is a bad practice. Also there is no check for zero. Proof of Concept Tools Used Code analytics Recommended Mitigation Steps Create method acceptAdmin and and check for zero address. --- The text was updated successfull...

Lack of a contract existence check may lead to undefined behavior

Lines of code Vulnerability details Impact Low-level calls call/delegatecall/staticcall return true even if the account called is non-existent per EVM design. Solidity documentation warns: “The low-level functions call, delegatecall and staticcall return true as their first return value if the...

USE SAFEERC20 (SAFEAPPROVE/SAFEMINT/SAFETRANSFERFROM) INSTEAD OF APPROVE/MINT/TRANSFER FROM

Lines of code Vulnerability details Impact The classic openzepplin implementation of the ERC20 standard ie. functions : Approve, Transfer, TransferFrom and mint does not capture the fact that some ERC20 token do not return a boolean value eg. BNB, USDT, OMG. As results, these functions won't work...

Governor can rug pull the escrow

Lines of code Vulnerability details Impact Governor can rug pull all GRT held by BridgeEscrow, which is a severe undermining of decentralization. Proof of Concept The governor can approve an arbitrary address to spend any amount from BridgeEscrow, so they can steal all escrowed tokens. Even if th...

Use safeTransferFrom instead of transferFrom()

Lines of code Vulnerability details Impact Although ERC20 standard suggests that a transfer should return true on success, there are tokens that doesn't comply with this. Therefore, the transferFrom call might cause silent failures and will affect the token accounting in this contract. Proof of...

The arithmetic operator can overflow

Lines of code Vulnerability details Impact It is possible to cause an integer overflow or underflow in the arithmetic operation. Description An overflow/underflow happens when an arithmetic operation reaches the maximum or minimum size of a type. For instance if a number is stored in the uint8...

Ignores return value from L1GraphTokenGateway.outboundTransfer

Lines of code Vulnerability details Impact Not tracking values returned by token transfer from. So from was getted from parseOutboundData, and if encoded data is wrong, this can return not expected from address. Then from will passed into transferFrom and it not approve for escrow or allowance is...

UNSAFE USAGE OF ERC20 TRANSFERFROM

Lines of code Vulnerability details Impact Ignores return value from L1GraphTokenGateway.finalizeInboundTransfer and L1GraphTokenGateway.outboundTransfer Not tracking values returned by token transfer from. finalizeInboundTransfer When escrow not approve for L1GraphTokenGateway or allowance is no...

The arithmetic operator can overflow

Lines of code Vulnerability details Impact It is possible to cause an integer overflow or underflow in the arithmetic operation. Proof of Concept Contract: GraphProxyAdmin Function name: getProxyPendingImplementationaddress PC address: 1898 Estimated Gas Usage: 1387 - 36513 In file:...

Multichain signature reuse risk when use the signature to grant allowance permission in GraphTokenUpgradeable.sol

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. The GraphTokenUpgradeable support the usage of offline signature to approve token spending. However, there is Multichain signature reuse risk when user signing the signature, the attacker can take the...

Buyers will lose an amount of their funds for only one ERC115 token

Lines of code Vulnerability details Impact By using StandardPolicyERC1155.sol as a matchingPolicy for the order. The buyer will transfer an amount of funds ETH or WETH for 2 or more tokens, but he will receive only 1 token. Proof of Concept in case the buyer has set Input.Order.amount 1. Let’s sa...

Buyer can receive chargeback from fees.

Lines of code Vulnerability details Impact Since there is no check on who the fees.recipient is in the sell order, the buyer could be the fees recipient, with some additional signature malleability to pass the signature validation, the buyer would receive fees, thus pay less for the NFT. Proof of...

blockRange can equal zero which may break oracle authorization

Lines of code Vulnerability details Impact An order cant be filled when its outside of the blockRange. Without a minimumBlockRange its possible for the blockRange to be 0 which would prevent any orders relying on the oracle to be filled Proof of Concept A buyer calls execute to fill an order The...