10190 matches found
In gauge, checkpoint.voted is incorrectly copied from previous checkpoint (always false in new checkpoint)
Lines of code Vulnerability details Impact When a user interacts with a gauge and a new balance checkpoint is created in storage of this gauge, then checkpoint.voted for this new checkpoint is always false. Unless users are aware of this bug and call voter.poke after each interaction with the gau...
Bribe.sol Tokens with fee on transfer are not supported
Lines of code Vulnerability details There are ERC20 tokens that charge fee for every transfer or transferFrom. In the current implementation, Bribe.solnotifyRewardAmount assumes that the received amount is the same as the transfer amount, and uses it to calculate reward amounts. As a result, in...
Gauge Functionalities Still Accessible After Being "Killed"
Lines of code Vulnerability details Proof-of-Concept The Voter contract contains a killGauge function that allow the emergency council to kill a gauge. The killGauge function will set the isAlive mapping to false. Thus, calling Voter's functions e.g. Voter.updateGauge, Voter.distributegauge again...
Rewards can be locked in Bribe contract because distributing them is depend of base token reward amount and Gauge.deliverBribes() is not get called always by Voter.distribute()
Lines of code Vulnerability details Impact Voter.distribute calls Gauge.deliverBribes if claimablegauge / DURATION 0 was True and claimablegauge shows base token rewards for gauge. Gauge.deliverBribes calls Bribe.deliverReward which transfers the rewards to Gauge. so for Bribe rewards to been...
Bribe Rewards Not Claimable By Voters
Lines of code Vulnerability details Background Based on the code of Gauge contract, there are two types of rewards that can be claimed from the Gauge contract by its users. 1. Gauge Rewards - For users Liquidity providers who deposit their LP tokens a.k.a LP Token Staker into the liquidity gauge...
Wrong reward distribution in Bribe because deliverReward() won't set tokenRewardsPerEpoch[token][epochStart] to 0
Lines of code Vulnerability details Impact Function deliverReward in Bribe contract won't set tokenRewardsPerEpochtokenepochStart to 0 after transferring rewards. Gauge.getReward calls Voter.distribute which calls Gauge.deliverBribes which calls Bribe.deliverReward. so if Gauge.getReward or...
Gauge Rewards Not Claimable By LP Token Stakers
Lines of code Vulnerability details Background Based on the code of Gauge contract, there are two types of rewards that can be claimed from the Gauge contract by its users. 1. Gauge Rewards - For users Liquidity providers who deposit their LP tokens a.k.a LP Token Staker into the liquidity gauge...
Repeated calls to deliverBribes() risks draining bribe of assets into Gauge
Lines of code Vulnerability details Impact Funds drain from Bribe prematurely with repeated calls to deliverBribes Proof of Concept Calling deliverBribes calls deliverRewards which transfers the amount specified as the rewards due and sends to gauge. Repeated calls to deliverBribes makes repeated...
Anyone can add Gauge reward tokens and cause DoS
Lines of code Vulnerability details Impact The Gauge.notifyRewardAmount function does not have any access restriction. Anyone an attacker can frontrun and call this function to add arbitrary even malicious gauge reward tokens up to MAXREWARDTOKENS = 16. An attacker is able to frontrun and add 16...
Voting overwrites checkpoint.voted in last checkpoint, so users can just vote right before claiming rewards
Lines of code Vulnerability details Impact if cp0.voted reward += cp0.balanceOf rewardPerTokenStored1 - rewardPerTokenStored0 / PRECISION; this line in gauge.earned function looks like the intention here is to incentivize users to keep their escrow.balanceOfNft voted for this gauge. However, it's...
Unauthorized notifyRewardAmount
Lines of code Vulnerability details Impact Anyone can trick Bribe and Gauge contracts by calling notifyRewardAmount with arbitrary tokens until MAXREWARDTOKENS is reached. However, later team can replace these fake tokens by calling swapOutRewardToken. However, still, a malicious actor can force...
Missing events/timelock for function updateChannel only functions that change critical parameters
Lines of code Vulnerability details Impact functions that change critical parameters should emit events and have timelocks. Events allow capturing changed parameters so interfaces can register changes with timelock. It allow users to evaluate them and consider if they would like to engage or exit...
In Bribe, tokenRewardsPerEpoch isn't decreased after transferring the rewards
Lines of code Vulnerability details Impact DoS issues when users try to claim rewards. Proof of Concept tokenRewardsPerEpochtokenadjustedTstamp for a given epoch only increases when bribe.notifyRewardAmount is called and never decreases. Before it's called first time in a given epoch, this value...
Bribe Rewards Struck In Contract If Deposited During First Epoch
Lines of code Vulnerability details Vulnerability Details Bribe rewards added to the Bribe contract in the first epoch will not be claimable by any voters, and the rewards will struck in the Bribe contract. Proof-of-Concept Assume that the current epoch is epoch 0, and start date of epoch 0 is Da...
Consistently check account balance before and after transfers for Fee-On-Transfer discrepancies
Lines of code Vulnerability details As arbitrary ERC20 tokens can be passed, the amount here should be calculated every time to take into consideration a possible fee-on-transfer or deflation. Also, it's a good practice for the future of the solution. Affected code: contracts/contracts/Bribe.sol:...
Upon burn, token is not removed from delegate token list
Lines of code Vulnerability details VotingEscrew burn function does not remove the token from the token's delegate token list. Impact Wrong voting results. Delegate's votes will be inflated. Proof of Concept When minting a token, it is added to the owner's delegate using moveTokenDelegates:...
Once-off setter functions can be set multiple times
Lines of code Vulnerability details Impact The once-off setter functions don't use require to limit, resulting in multiple calls. Proof of Concept RewardsDistributor.sol // Once off event on contract initialize function setDepositoraddress depositor external requiremsg.sender == depositor;...
_writeCheckpoint() in Gauge use wrong index to get prevVoteStatus
Lines of code Vulnerability details Impact All the Voting values calculated by writeCheckpoint when it's not first checkpoint is going to set to False instead of account's last vote and because vote has been used in earned and reward calculation so reward distribution is going to be wrong too...
Must approve 0 first
Lines of code Vulnerability details Impact Some tokens like USDT do not work when changing the allowance from an existing non-zero allowance value.They must first be approved by zero and then the actual allowance must be approved. Proof of Concept Tools Used Manual Review Recommended Mitigation...
Approved spender can not withdraw or merge
Lines of code Vulnerability details In the current implementation, withdraw and merge veNFT can be called by approved spender or token owner. function withdrawuint tokenId external nonreentrant assertisApprovedOrOwnermsg.sender, tokenId; function mergeuint from, uint to external...
functions deposit() and notifyRewardAmount() in Bribe and Gauge contract don't consider deflationary tokens when transferring
Lines of code Vulnerability details Impact The actual amount that has been transferred can be different than requested amount in deflationary tokens and this is not been addressed in transferring logic in the code. This can cause wrong calculation and rewards distribution for users. Proof of...
Bribe.sol is not meant to handle fee-on-transfer tokens
Lines of code Vulnerability details Impact Should a fee-on-transfer token be added as a reward token and deposited, the tokens will be locked in the Bribe contract. Voters will be unable to withdraw their rewards. Proof of Concept Tokens are deposited into the Bribe contract using...
Bribe Rewards Not Collected In Current Period Will Be Lost Forever
Lines of code Vulnerability details High Bribe Rewards Not Collected In Current Period Will Be Lost Forever Vulnerability Details It was observed that if the bribe rewards are not collected in the current period, they will not be accrued to future epoch, and they will be lost forever...
If extra reward token is "protected token" it the rewards will be taken by other protocols
Lines of code Vulnerability details Impact Misallocation of extra reward tokens Proof of Concept Let's think of a scenario where CRV is being used as an extra incentive for a pickle finance gauge. The extra rewards will be sent to voterProxy but when the extra rewards stash tries to claim them, t...
Users can get unlimited votes
Lines of code Vulnerability details Impact Users can get unlimited votes which leads to them: 1. gaining control over governance 2. getting undeserved rewards 3. having their pools favored due to gauge values Proof of Concept mint calls moveTokenDelegates to set up delegation... File:...
Incorrect msg.value usage could lead to fund loss
Lines of code Vulnerability details Impact The burnToTarget function is using msg.value in a loop which is passed to swapAll function of swapperRouter. Since msg.value amount will not change within loop, contract will end up using its own ETH Proof of Concept 1. User calls burnToTarget function...
User will get free funds
Lines of code Vulnerability details Impact If contract has an existing balance of WETH, ETH or targetUnderlying then user will get extra funds. Proof of Concept 1. Assume contract has existing amount 10 of targetUnderlying token 2. User calls burnToTarget function which converts all his passed...
GettersAndDerivers: Offer and consideration should be sorted when calculating orderHash
Lines of code Vulnerability details Impact When calculating the orderHash in the deriveOrderHash function of the GettersAndDerivers contract, the orderHash will be different due to the order of the elements in the offer and consideration, and the user is likely to get the wrong orderHash due to t...
DOS by creating large amount of SupplyCheckpoint
Lines of code Vulnerability details Impact An attacker can repeatedly call withdrawToken to create a large amount of SupplyCheckpoint. When there is a large amount of pending SupplyCheckpoint, updateRewardPerToken might revert due to out-of-gas when trying to processing all the checkpoints, rewar...
Upgraded Q -> M from 94 [1653831846680]
Judge has assessed an item in Issue 94 as Medium risk. The relevant finding follows: --- The text was updated successfully, but these errors were encountered: All reactions...
withdraw() and merge() functions of VotingEscrow won't work when an approved user(not owner) calls because _burn() function fails.
Lines of code Vulnerability details Impact withdraw and merge functions of VotingEscrow won't work when an approved usernot owner calls. Proof of Concept withdraw and merge functions call burn function inside and burn function calls removeTokenFrom using msg.sender. But removeTokenFrom requires...
Voting Escrow System could be wrapped and made useless without contract whitelisting
Lines of code Vulnerability details Impact Anyone could create a contract or a contract factory, say āVelo Locker" with a fonction to deposit VELO tokens through a contract, lock them and delegate the voting power to the contract owner. Then, the ownership of this contract could be sold, or the...
Upgraded Q -> M from 26 [1653831187876]
Judge has assessed an item in Issue 26 as Medium risk. The relevant finding follows: --- The text was updated successfully, but these errors were encountered: All reactions...
Attacker can block LayerZero channel
Lines of code Vulnerability details Impact According to the LayerZero docs, the default behavior is that when a transaction on the destination application fails, the channel between the src and dst app is blocked. Before any new transactions can be executed, the failed transaction has to be retri...
Wrong parameter in _removeTokenFrom call from _burn internal function
Lines of code Vulnerability details Impact Break the posibility of third party callapprove or approvalForAll authorization to withdraw and merge functions what use the burn internal function Proof of Concept If somebody use the withdraw or merge functions as third party "operator" with approve or...
OrderValidator: The _cancel function does not validate the order status, the order will be cancelled even if the order does not exist.
Lines of code Vulnerability details Impact In the cancel function of the OrderValidator contract, orderStatusorderHash.isValidated is not checked. If the user's input is incorrect, the non-existing order will be cancelled without any message, causing the user to think that the correct order has...
unsafe call using msg.value in loop
Lines of code Vulnerability details description with the function burnToTarget in FeeBurner.sol, a malicious user can swap more funds than they input in ETH if they include multiple address0 in the addresses tokens parameter during the function call, there is a for loop that loops through tokens...
First depositor can break minting of shares
Lines of code Vulnerability details Impact The attack vector and impact is the same as TOB-YEARN-003, where users may not receive shares in exchange for their deposits if the total asset amount has been manipulated through a large ādonationā. Proof of Concept In BathToken.sol:569-571, the...
BathToken.sol#_deposit() attacker can mint more shares with re-entrancy from hookable tokens
Lines of code Vulnerability details BathToken.soldeposit calculates the actual transferred amount by comparing the before and after balance, however, since there is no reentrancy guard on this function, there is a risk of re-entrancy attack to mint more shares. Some token standards, such as ERC77...
QA Report
Impact RubiconRouter.swapEntireBalance is supposed to buy at least buyamtmin of Y output tokens by using the caller's entire X input token balance. The problem is that instead of passing the buyamtmin minus the fee to swap, the code uses the caller's X token balance, maxAmount. This means the cal...
Wrong fee calculation between Router & Market
Lines of code Vulnerability details Impact The wrong fee calculation can cause a loss to users' fund and this loss will be stuck in RubiconRouter Proof of Concept We have the default $feeBPS = 20, BPS = 10000$ Let's assume that alice call RubiconRouter.swappayamt=1000000 Through router, alice wil...
Anyone can cancel orders from the router and get the tokens
Lines of code Vulnerability details Impact Anyone can cancel orders from the router and get the tokens Proof of concept -A user makes a WETH order from the router -Any attacker can call the cancel function with the order ID and get all the unfilled funds from the order Basically orders in the...
Wrong buy_amt_min calculation in RubiconRouter.swapEntireBalance for multi-hop swaps
Lines of code Vulnerability details Impact The buyamountmin value provided for the swap call is calculating too few fees for multi-hop swaps. Every swap within a multi-hop swap is taking fees. Currently, only a one-time fee is calculated on the basis of the swapEntireBalance function parameter...
Orders sent with RubiconRouter Will get fulfilled in the router and tokens will be Lost
Lines of code Vulnerability details impact Users of the router will lose their funds proof of concept -Users can send orders from the router using offerForEth or offerWithEth -In order creation msg.sender will be the router since the router calls the market If the order doesn't get instantaneousl...
Multi-hop routes will leave a dust trail
Lines of code Vulnerability details Impact By calling RubiconMarket.buyid, quantity as a consequence of L239 and L241 with quantity = currentAmount - currentAmount expectedMarketFeeBPS / 10000 ...the fee calculated by the buy function amounts to: currentAmount - currentAmount expectedMarketFeeBPS...
Reentrancy attack
Lines of code Vulnerability details Impact High impact. Reentrancy Attack may lead in lost of funds. Proof of Concept Reentrancy in RubiconMarket.matchouint256,ERC20,uint256,ERC20,uint256,bool c ontracts/RubiconMarket.sol1049-1108: External calls: - buybestmakerid,minmpayamt,t...
DoS on deposit(), incrementLock() and createLock() because of a safeApprove(0)
Lines of code Vulnerability details Impact Since SafeERC20 is the one implemented by OpenZeppelin, if one checks the code at this address: You will see that the safeApprove executes this validation: require value == 0 || token.allowanceaddressthis, spender == 0, "SafeERC20: approve from non-zero ...
First pool depositor can break minting of shares
Lines of code Vulnerability details Impact First depositor of the pool can break minting of the Bath Token shares Proof of Concept An attacker -who is the first one to deposit- sends 1 wei and bypasses totalSupply == 0 condition. Later a very large amount of donation to the pool and inflates the...
BathPair.sol#rebalancePair() can be front run to steal the pending rebalancing amount
Lines of code Vulnerability details function underlyingBalance public view returns uint256 uint256 pool = IERC20underlyingToken.balanceOfaddressthis; return pool.addoutstandingAmount; function removeFilledTradeAmountuint256 amt external onlyPair outstandingAmount = outstandingAmount.subamt; emit...
Wrong formula to calculate new t_pay_amt in _matcho function (RubiconMarket.sol)
Lines of code Vulnerability details Impact functionmatcho won't work as expected tpayamount updated incorrectly can lead to reverted transaction because not enough fund to transfer Proof of Concept In matcho function, after matching with offer, tbuyamt and tpayamt will updated as follow: tbuyamto...