Missing ReEntrancy Guard to Withdraw function

Lines of code Vulnerability details Impact Missing ReEntrancy Guard to Withdraw function Proof of Concept There is no re-entry risk on true ERC-20 tokens that work according to the spec i.e. audited, etc.. However you can write a malicious ERC-20 with custom transferFrom or approve that have...

[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...

Use safeTransferFrom() function instead of transferFrom()

Lines of code Vulnerability details Impact The transferFrom method is used in the contract PartyGovernanceNFT.sol, I however argue that this isn’t recommended because: OpenZeppelin’s documentation discourages the use of transferFrom, use safeTransferFrom whenever possible Given that any NFT can b...

ERC20.sol is susceptible to classic ERC20 approve functionality front-running exploit

Lines of code Vulnerability details Proof of concept The problem is perfectly described here The tldr; is that if you approved a person to spend 100 tokens and then you want to decrease his allowance to 50, if he spends his 100 tokens allowance before you set his allowance to 50 he will be able t...

# _safeMint() should be used rather than _mint() wherever possible

Lines of code Vulnerability details safeMint should be used rather than mint wherever possible Impact In Token.sol.sol, eventually it is called ERC721 mint. Calling mint this way does not ensure that the receiver of the NFT is able to accept them, making possible to lose them. safeMint should be...

transferFrom() failure in _safeTransferFrom() could drain the pair

Lines of code Vulnerability details Impact For some tokens, tokenCon.transferFrom could fail and return false but not revert. Some malicious user can abuse it the addLiquidity/addLiquidityCANTO function to perform failure transferFrom but still get the liquidity, and later remove liquidity to dra...

Lack of check if token is a contract

Lines of code Vulnerability details Impact TransferHelper.sol and solmate won't check if the token is a contract or not. A hacker could set traps for non existing tokens to steal future funds from users. Proof of Concept The safeTransfer functions used in the contract are wrappers around the...

ERC20 return value not checked and not compatible with tokens like USDT, OMG, etc

Lines of code Vulnerability details ERC20 return value not checked and not compatible with tokens like USDT, OMG, etc Detail The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter needs to be checked for success. Furthermore, some tokens like...

TRSRY.sol is susceptible to ERC20 approve functionality front-running exploit

Lines of code Vulnerability details Proof of concept The problem is perfectly described here The tldr; is that if you approved a person to spend 100 tokens and then you want to decrease his allowance to 50, if he spends his 100 tokens allowance before you set his allowance to 50 he will be able t...

# ERC20 transfer / transferFrom with not checked return value

Lines of code Vulnerability details ERC20 transfer / 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. Code doesn't check return...

The repository uses versions of OpenZeppelin libraries with critical severity vulnerabilities

Lines of code Vulnerability details Proof of Concept The project uses 4.1.0 for both @openzeppelin/contracts and @openzeppelin/contracts-upgradeable but OpenZeppelin has flagged them as versions with critical severity vulnerability: GHSA-5vp3-v4hc-gx76 Also in those versions you have this...

Voting signature malleability of EVM's ecrecover in castVoteBySig

Lines of code Vulnerability details Proof of Concept EVM's ecrecover is susceptible to signature malleability which allows replay attacks, but that is mitigated here by doing receipt.hasVoted = true;. However, if any of the application logic changes, it might make signature malleability a risk fo...

Update initializer modifier to prevent reentrancy during initialization

Lines of code Vulnerability details package.json L32-33 The solution uses: "@openzeppelin/contracts": "^4.1.0", "@openzeppelin/contracts-upgradeable": "^4.1.0", The current implementation of initialize function in both NounsDAOLogicV1.sol and NounsDAOLogicV2.sol are not using initializer modifier...

Openzeppelin contracts with critical and high vulnerabilities can be installed and used

Lines of code Vulnerability details Impact Currently, @openzeppelin/contracts and @openzeppelin/contracts-upgradeable versions are set as follows. "@openzeppelin/contracts": "^4.1.0", "@openzeppelin/contracts-upgradeable": "^4.1.0", For the specified version, there are some critical and high...

Storage collision between proxy and logic v2

Lines of code Vulnerability details The lack of using EIP1967 proposal can lead to a storage collision on variables when implementing proxy-implementation pattern. More details can be found here; Impact Since the project implementing proxies with logic and implementation pattern where they share...

GHSA-4H98-2769-GH6H OpenZeppelin Contracts vulnerable to ECDSA signature malleability

Impact The functions ECDSA.recover and ECDSA.tryRecover are vulnerable to a kind of signature malleability due to accepting EIP-2098 compact signatures in addition to the traditional 65 byte signature format. This is only an issue for the functions that take a single bytes argument, and not the...

OpenZeppelin Contracts vulnerable to ECDSA signature malleability

Impact The functions ECDSA.recover and ECDSA.tryRecover are vulnerable to a kind of signature malleability due to accepting EIP-2098 compact signatures in addition to the traditional 65 byte signature format. This is only an issue for the functions that take a single bytes argument, and not the...

OpenZeppelin Contracts's GovernorVotesQuorumFraction updates to quorum may affect past defeated proposals

Impact This issue concerns instances of Governor that use the module GovernorVotesQuorumFraction, a mechanism that determines quorum requirements as a percentage of the voting token's total supply. In affected instances, when a proposal is passed to lower the quorum requirement, past proposals ma...

GHSA-XRC4-737V-9Q75 OpenZeppelin Contracts's GovernorVotesQuorumFraction updates to quorum may affect past defeated proposals

Impact This issue concerns instances of Governor that use the module GovernorVotesQuorumFraction, a mechanism that determines quorum requirements as a percentage of the voting token's total supply. In affected instances, when a proposal is passed to lower the quorum requirement, past proposals ma...

Not calling approve(0) before setting a new approval might cause reverts when used with Tether (USDT)

Lines of code Vulnerability details Impact Some tokens do not implement the ERC20 standard properly but are still accepted by most code that accepts ERC20 tokens. For example Tether USDT's approve function will revert if the current approval is not zero, to protect against front-running changes o...