Reentrancy vulnerability in USDO.flashLoan() function

Lines of code Vulnerability details Impact The reentrancy vulnerability in the USDO contract could allow an attacker to withdraw funds from the contract even if the original contract has not yet approved the withdrawal. This could result in a loss of funds for the USDO contract and its users. Pro...

Position created with BNB as collateral will result in locked collateral

Lines of code Vulnerability details withdrawCollateral allows position owners to withdraw collateral from the position - as long as it is still collateralized afterwards. File: Position.sol 263: function withdrawCollateraladdress target, uint256 amount public onlyOwner noChallenge noCooldown 264:...

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

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

Some tokens may break VotingScrow contract in transfer and transferFrom functions

Lines of code Vulnerability details Vulnerability details Some ERC20 tokens such as USDT don't return boolean values from transfer and transferFrom methods. The require checks will therefore revert causing the functions to be unusable. Impact This would prevent withdraw and createLock functions t...

Upgraded Q -> M from 243 [1655572117784]

Judge has assessed an item in Issue 243 as Medium risk. The relevant finding follows: Title: Using SafeERC20 library in ForgottenRunesWarriorsMinter.sol There are some token which are not implementing current ERC20 standard example: USDT, OmiseGo and BNB. Using SafeERC20 library will be nice to...

Unchecked transfers may lead to funds lost.

Handle bobi Vulnerability details Impact There are some transferFrom and transfer calls without checking the resultseg. against reverting. Moreover, for certain ERC20 tokens, should insufficient tokens be present, no revert occurs whatsoever, and instead, a "false" value is returned, which should...

uToken's approve() Function is Susceptible to Frontrunning Attacks

Handle leastwood Vulnerability details Impact Order makers will call the approve function to facilitate transactions between order takers and makers. If a taker sees that a maker is seeking to reduce its order exposure by reducing Swivel.sol's allowance, a taker can frontrun this transaction to...

Use safeTransfer instead of transfer

Handle shw Vulnerability details Impact Tokens not compliant with the ERC20 specification could return false from the transfer function call to indicate the transfer fails, while the calling contract would not notice the failure if the return value is not checked. Checking the return value is a...

Unchecked token transfers

Handle Lucius Vulnerability details Impact The functions transerFrom/transer do not revert on failure and instead simply return false. Without checks on the return values, the transfers could potentially fail silently allowing unexpected issues with certain token pools. E.G. If a user calls depos...

Return values of ERC20 transfer and transferFrom are unchecked

Handle shw Vulnerability details Impact In the contract RCTreasury, the return values of ERC20 transfer and transferFrom are not checked, which could be false if the transferred token is not ERC20-compliant. In that case, the transfer fails without being noticed by the calling contract. Proof of...