Return values of ERC20 transfer and transferFrom are unchecked

Handle shw Vulnerability details Impact In some contracts e.g., TracerPerpetualSwaps.sol, the return values of ERC20 transfer and transferFrom are not checked to be true, which could be false if the transferred tokens are not ERC20-compliant. In that case, the transfer fails without being noticed...

SafetyWithdraw ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter should be checked for success. The SafetyWithdraw.withdrawERC20Token function does not check the return value: function withdrawERC20Token address...

No check transferFrom() return value

Handle s1m0 Vulnerability details Impact The smart contract doesn't check the return value of token.transfer and token.transferFrom, some erc20 token might not revert in case of error but return false. In the TracerPerpetualSwaps:deposit and Insurance:deposit this would allow a user to deposit fo...

Insurance ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter should be checked for success. The Insurance.deposit and Insurace.withdraw functions dp not check the return value: // deposit...

BadgerYieldSource ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter needs to be checked for success. Some tokens do not revert if the transfer failed but return false instead. It is not checked in...

safeApprove() for Yearn Vault may revert preventing deposits causing DoS

Handle 0xRajeev Vulnerability details Impact The depositInVault function for Yearn yield source uses ERC20 safeApprove from OpenZeppelin's SafeERC20 library to give maximum allowance to the Yearn Vault address if the current allowance is less than contract’s token balance. However, the safeApprov...

usage of safeApprove

Handle pauliax Vulnerability details Impact depositInVault in contract YearnV2YieldSource calls safeApprove when the allowance is less than the token balance: if token.allowanceaddressthis, addressv token.balanceOfaddressthis token.safeApproveaddressv, typeuint256.max; This does not mean that the...

Problems with non-standard compliant ERC20 tokens

Handle cmichel Vulnerability details Vulnerability Details Some tokens like USDT don't correctly implement the EIP20 standard and their transfer/transferFrom function return void instead of a success boolean. Calling these functions with the correct EIP20 function signatures will always revert...

Missing checkOnERC721Received deviates from ERC721 and could lock/lose NFTs

Handle 0xRajeev Vulnerability details Impact ERC721 specification for safeTransferFrom says: “this function checks if to is a smart contract code size 0. If so, it calls onERC721Received on to and throws if the return value is not bytes4keccak256“onERC721Receivedaddress,address,uint256,bytes”.”...

Unchecked return value from ERC20

Handle cmichel Vulnerability details Vulnerability Details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter needs to be checked for success. According to the standard the return value must be checked for true, otherwise the transfer wil...

Unchecked ERC20 transfers can cause lock up

Handle axic Vulnerability details Impact Some major tokens went live before ERC20 was finalised, resulting in a discrepancy whether the transfer functions a should return a boolean or b revert/fail on error. The current best practice is that they should revert, but return “true” on success...

Unchecked return value of transfer in NFTXFeeDistributor

Handle shw Vulnerability details Impact The function rescueTokens in the contract NFTXFeeDistributor does not check the return value of transfer. It is possible that the transferred assets are not ERC20-compliant e.g., returns a false when a transfer fails, leading to unexpected results. Proof of...

Reentrancy Attack

openzeppelin-solidity is vulnerable to reentrancy attack. The vulnerability exists when a extend custom beforeTokenTransfer is invoked when burning tokens and before the send hook is externally called on the sender while token balances are adjusted after the process and this may cause the...