Upgraded Q -> M from 268 [1654474507101]

Judge has assessed an item in Issue 268 as Medium risk. The relevant finding follows: High feeRate can break core protocol function PROBLEM There is no maximum input value on setFee in Cally.sol. But if the owner sets it to a uint greater than 1e18, the users will not be able to call exercice as...

Upgraded Q -> M from 286 [1654474962848]

Judge has assessed an item in Issue 286 as Medium risk. The relevant finding follows: No min/max fee rate Line Refrences Cally.solL119-121 Description Limits for the fee rate should be set to avoid mistakes when setting the fee. A fee rate that is over 100% could result in the exercise function n...

Upgraded Q -> M from 135 [1654503715861]

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

Upgraded Q -> M from 103 [1654497041670]

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

Upgraded Q -> M from 131 [1654475029272]

Judge has assessed an item in Issue 131 as Medium risk. The relevant finding follows: Recommend using safeTransferFrom instead of transferFrom for NFTs The EIP-721 standard states: /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE /// TO CONFIRM THAT to IS CAPABLE OF RECEIVING...

Upgraded Q -> H from 135 [1654503748167]

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

Upgraded Q -> M from 174 [1654475154140]

Judge has assessed an item in Issue 174 as Medium risk. The relevant finding follows: feeRate Can Be Set to 100% Permalinks Description There is no maximum limit on how high the feeRate can be, which might result in a fee rate of 100%, meaning the protocol will collect every ether sent in...

Upgraded Q -> M from 41 [1654474648312]

Judge has assessed an item in Issue 41 as Medium risk. The relevant finding follows: L02: Lack of upper bound for feeRate Line References Description Fees can be set above 1e18, preventing options from being exercised. Recommended Mitigation Steps Consider having a hard cap of x% 100%. // Eg. cap...

Upgraded Q -> H from 69 [1654495749150]

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

Upgraded Q -> M from 37 [1654474354289]

Judge has assessed an item in Issue 37 as Medium risk. The relevant finding follows: Missing sanity check in setFeeRate There is no input validation in setFeeRate. A faulty payload could set the feeRate to a very high amount, which would cause problems when options are exercised: Loss of fund for...

Upgraded Q -> M from 95 [1654474439349]

Judge has assessed an item in Issue 95 as Medium risk. The relevant finding follows: Incompatability with deflationary / fee-on-transfer tokens Function Cally.createVault function takes a tokenIdOrAmount parameter but this parameter is not the actual transferred amount for fee-on-transfer /...

Upgraded Q -> M from 98 [1654475216526]

Judge has assessed an item in Issue 98 as Medium risk. The relevant finding follows: Set Limits on setFee A Malicious owner could set feeRate to = 100 1e18 / 100; which would give the entire value of an exercise transaction to the protocol, create a limit on the fees the owner can set. --- The te...

Upgraded Q -> H from 103 [1654497033247]

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

Upgraded Q -> M from 135 [1654503723748]

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

Upgraded Q -> M from 119 [1654475092615]

Judge has assessed an item in Issue 119 as Medium risk. The relevant finding follows: Checking whether the receiver is capable of holding ERC721 The contract usessafeTransfer for ERC20 but uses transferFrom for ERC721 in both exercise and withdraw which may lead to the loss of ERC721 if the...

Upgraded Q -> H from 63 [1654488227536]

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

Upgraded Q -> M from 74 [1654474884998]

Judge has assessed an item in Issue 74 as Medium risk. The relevant finding follows: Protocol does not support fee-on-transfer tokens The tokenIdOrAmount established in createVault prevents buyers from exercise their option because addressthis holds less than tokenIdOrAmount due to the transfer...

Upgraded Q -> M from 74 [1654474712630]

Judge has assessed an item in Issue 74 as Medium risk. The relevant finding follows: Use of transferFrom instead of safeTransferFrom Cally.solL295 When buyers exercise the transferFrom function is used instead of safeTransferFrom. In the very unlikely event the receiving contract is somehow not...

Upgraded Q -> M from 294 [1654474576938]

Judge has assessed an item in Issue 294 as Medium risk. The relevant finding follows: Owner can frontrun exercise to increase fees A malicious owner account can observe and frontrun calls to exercise and extract 100% of the strike price as a protocol fee. Scenario: A malicious owner observes a ca...

Upgraded Q -> M from 137 [1654449389324]

Judge has assessed an item in Issue 137 as Medium risk. The relevant finding follows: It does not even check the return value and a low-level call succeeds if the address is empty or non-existent. dexMapping is a manually operated config so it may not contain info for all collateral tokens, and i...

Upgraded Q -> M from 104 [1654442859269]

Judge has assessed an item in Issue 104 as Medium risk. The relevant finding follows: Check transfer receiver is not 0 to avoid burned money Transferring tokens to the zero address is usually prohibited to accidentally avoid "burning" tokens by sending them to an unrecoverable zero address. Code...

Upgraded Q -> M from 104 [1654443194486]

Judge has assessed an item in Issue 104 as Medium risk. The relevant finding follows: transfer return value of a general ERC20 is ignored Need to use safeTransfer instead of transfer. As there are popular tokens, such as USDT that transfer/trasnferFrom method doesn’t return anything. The transfer...

Upgraded Q -> M from 87 [1654442977298]

Judge has assessed an item in Issue 87 as Medium risk. The relevant finding follows: Issue 3 Low - Some tokens do not allow for Non-Zero to Non-Zero value approvals USDT, for example, will not allow approving a non-zero amount and then approving another non-zero amount. The approval must be reset...

Upgraded Q -> M from 124 [1654443300023]

Judge has assessed an item in Issue 124 as Medium risk. The relevant finding follows: C4-007 : USE SAFEERC20.SAFEAPPROVE Impact This is probably an oversight since SafeERC20 was imported and safeTransfer was used for ERC20 token transfers. Nevertheless, note that approve will fail for certain tok...

Upgraded Q -> M from 114 [1654442763376]

Judge has assessed an item in Issue 114 as Medium risk. The relevant finding follows: PROBLEM All external functions that can be called by users should have comments SEVERITY Non-Critical PROOF OF CONCEPT Instances include: SuperVaultFactory.sol SuperVaultFactory.sol:23: function clonebytes...

Upgraded Q -> M from 124 [1654442937681]

Judge has assessed an item in Issue 124 as Medium risk. The relevant finding follows: C4-006 : The Contract Should Approve0 first Impact Some tokens like USDT L199 do not work when changing the allowance from an existing non-zero allowance value. They must first be approved by zero and then the...

Integer Overflow in Nonce Possible Via EIP 1271 Compliant Contract

Lines of code Vulnerability details Impact The current NonceManager deployed version does not expect a nonce to go as high to actually trigger an integer overflow and is therefore, unchecked. However, it is completely possible to have the nonce go as high with EIP 1271 contracts that hold the NFT...

_verifyProof allows empty proofs (allows malleable transactions)

Lines of code Vulnerability details Impact verifyProof allows empty proofs and in that case it expects the leaf to equal the root, because no hashing and iteration is taking place. The purpose of the tree is to hold multiple accepted tokenIds, where the consideration contains one and proving its...

Buyer can take from a seller an item they had not offered

Lines of code Vulnerability details Impact Orders in Seaport can involve "criteria-based items", in which case it isn't one specific item that can fulfill the order but any one of a set of items. This set of items is the "criteria", and it is specified in the order as the merkle root of a merkle...

Fulfill transactions that are not protected with a deadline may lead to unfavorable trade.

Lines of code Vulnerability details Impact A fulfill transaction of order with descending/ascending amount should be protected by the deadline. The price of an order with a descnding amount is sensitive to the time. Letting users make such a trade without providing the deadline would lead to...

Upgraded G -> H from 10 [1654286526568]

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

Order partial fulfilling can be blocked by the first fulfiller

Lines of code Vulnerability details DOS attack is possible as OrderValidator.validateOrderAndUpdateStatus sets order's numerator and denominator based on an arbitrary fulfiller provided input. When there is a large bulk sale, an attacker can become one of the first buyers partial fulfillers and s...

Inconsistency in view functions can lead to users believing they’re due for more BKD rewards

Lines of code Vulnerability details Impact The view functions used for a user to check their claimable rewards vary in their implementation. This can cause users to believe they are due X amount but will receive Y. Proof of Concept If the inflationRecipient is set, then poolStakedIntegral will be...

Fulfilling an order more than once

Lines of code Vulnerability details Impact Any non basic or FULL order can be fulfilled more than once, assuming the offerer has approved the contract the right amounts. This is a valid assumption as users may max-approve the contract/conduits, or have multiple orders with the same items open so...

Any user can start inflation for Minter.sol

Lines of code Vulnerability details Submitting as a high risk bug because it is equivalent to calling startInflation which is a function reserved for only governance to call and it drastically alters token distribution Impact Bypass governance only call restriction and cause immediate inflation...

QA Report

Reinitalisation in BkdLocker.sol In the initialize function, the only check is made that the current startBoost value is zero, if zero is passed then this allows the function to be reinitialised and potentially modifying other variables which should remain constant. Consider making a check that t...

Able to get LP tokens without spending any funds in FeeBurner.sol

Lines of code FeeBurner.solL43-L88 Vulnerability details Impact In the burnToTarget function, if the tokens array has only a zero address token and msg.value is 0 then FeeBurner.sol would still call the swapAll function and use all WETH held in the contract. If the contract has any WETH, the call...

Usage of deprecated transfer to send ETH

Lines of code Vulnerability details Impact Usage of deprecated transfer Swap can revert. Proof of Concept The original transfer used to send eth uses a fixed stipend 2300 gas. This was used to prevent reentrancy. However this limit your protocol to interact with others contracts that need more th...

More than 1 zero address token in burnToTarget may lead to draining of FeeBurner.sol

Lines of code FeeBurner.solL43-L88 Vulnerability details Impact The burnToTarget function in FeeBurner.sol allows any array of tokens to be used. If the tokens array contains more than 1 zero address, the swapAll function for the swapperRouter will be called more than once with the same msg.value...

BkdLocker#depositFees() can be front run to steal the newly added rewardToken

Lines of code Vulnerability details Every time the BkdLockerdepositFees gets called, there will be a surge of rewards per locked token for the existing stakeholders. This enables a well-known attack vector, in which the attacker will take a large portion of the shares before the surge, then claim...

StakerVault.unstake(), StakerVault.unstakeFor() would revert with a uint underflow error of StakerVault.strategiesTotalStaked, StakerVault._poolTotalStaked.

Lines of code Vulnerability details Impact StakerVault.unstake, StakerVault.unstakeFor would revert with a uint underflow error of StakerVault.strategiesTotalStaked, StakerVault.poolTotalStaked. Proof of Concept Currently it saves totalStaked for strategies and non-strategies separately. uint...

Minter.sol#_executeInflationRateUpdate() inflationManager().checkpointAllGauges() is called after InflationRate is updated, causing users to lose rewards

Lines of code Vulnerability details When Minter.solexecuteInflationRateUpdate is called, if an INFLATIONDECAYPERIOD has past since lastInflationDecay, it will update the InflationRate for all of the gauges. However, in the current implementation, the rates will be updated first, followed by the...

uint120 overflow for partially fillable orders in OrderValidator.sol

Lines of code Vulnerability details Repo commit referenced: 49799ce156d979132c9924a739ae45a38b39ecdd Impact In the lines OrderValidator.solL223-L239 where the orderStatus for an orderHash gets updated: orderStatusorderHash.numerator = uint120 filledNumerator + numerator ;...

A malicious zone operator can piggyback other transactions, when a caller tries to fulfill the restricted order

Lines of code Vulnerability details If an order has a restricted order type and, if the caller is other than the offerer or zone, then a staticcall to isValidOrder on the zone is made. This call outside the Seaport contract opens up a possible misuse by the zone contract implementation. The zone...

BurnToTarget can be exploited to receive more LP tokens

Lines of code Vulnerability details Issue: depositInPool uses addressthis.balance Consequences: exploiter will get more lp tokens File: FeeBurner.sol 81: // Depositing target underlying into target pool 82: uint256 targetLpTokenBalance = depositInPooltargetUnderlying, targetPool; 83: 84: //...

Contracts allow users to steal latent funds as their own

Lines of code Vulnerability details Impact Users that accidentally send Ether to contracts, or have rebasing rewards that the contract has stole because it doesn't properly track rebasing tokens, have their funds now latent stolen, so they can't be returned by an admin. Proof of Concept One examp...

Merkle Tree criteria can be resolved by wrong tokenIDs

Lines of code Vulnerability details Impact The protocol allows specifying several tokenIds to accept for a single offer. A merkle tree is created out of these tokenIds and the root is stored as the identifierOrCriteria for the item. The fulfiller then submits the actual tokenId and a proof that...

Underflow unchecked

Lines of code Vulnerability details Impact There is no check for underflow even though there is chance to be on Proof of Concept in The call for function locateCurrentAmount they said that duration !=0. But, there is this call where there duration = advancedOrder.parameters.endTime -...

RewardHandler.soland FeeBurner.sol will fail due to inexistent AddressProvider.sol getter functions

Lines of code Vulnerability details Impact FeeBurner.burnToTarget and RewardHandler.burnFees will fail every time because addressProvider.getSwapperRouter, addressProvider.getBKDLocker and addressProvider.getFeeBurner are not implemented in AddressProvider.sol. Proof of Concept getSwapperRouter,...

Call to safeApprove without checking previous allowance in burnFees could result in locked funds

Lines of code Vulnerability details Impact Using this deprecated function can lead to unintended reverts and potentially the locking of funds. A deeper discussion on the deprecation of this function is in OZ issue 2219 OpenZeppelin/openzeppelin-contracts2219. Proof Of Concept Refer to the burnFee...