Potential Unauthorized Flash Loan Execution and Share Burning due to Lack of Permission Checks

Lines of code Vulnerability details Impact The executeFlashloan function in the provided contract allows any user to execute a flash loan on behalf of another user without explicit permission. This could potentially lead to an unauthorized execution of flash loans and unexpected share burnings if...

Reentrancy may allow a customer to steal funds

Lines of code Vulnerability details Impact The reentrancy in the vested token can be used by a customer if the execution can be hijacked before the balance change occurs. Let’s consider function withdraw. Firstly, the balance is checked and then if there is enough token surplus to withdraw, the...

Incorrect poolTotalEUSDCirculation Calculation

Lines of code Vulnerability details Impact poolTotalEUSDCirculation calculated incorerctly so it can effect reward distribution Proof of Concept The following line of code deduces repaid amount from poolTotalEUSDCirculation while the fee that is part of repaid amount will be distribute as rewards...

distributeRewards can revert because of the too strict slippage check

Lines of code Vulnerability details Impact The report highlights that the distributeRewards function can revert due to a strict slippage check. The provided proof of concept demonstrates the issue, where the slippage is set to 98%, leading to potential transaction failures. Proof of Concept...

Calls to rigidRedemption can fail due to an underflow when collateralAsset price falls.

Lines of code Vulnerability details Impact When the collateralAsset price falls drastically a wrong collateralAmount is calculated in the line below from the eusdAmount. The collateralAmount calculated can be greater than the amount deposited by the provider in the rigidRedemption. Which leads to...

Withdraw fee discounting using self rigidRedemption

Lines of code Vulnerability details Description There is no restriction for self rigidRedemption so that allows one to repay and withdraw instantly part of the collateral. That allows us to instantly withdraw with less fee paid. Impact It may be used for malicious scenarios with flashloan for...

Voting period hardcoded to 3 blocks

Lines of code Vulnerability details Impact Here in the Governance contract, the voting period is locked to 3 blocks. function votingPeriod public pure override returns uint256 return 3; function votingDelay public pure override returns uint256 return 1; This is a direct bug because if we take a...

A minimum of 1/3 of total esLBR supply required for the proposal to pass

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. If a quorum is set too high, the minimum number of cast voted required for a proposal to be successful would be harder to reach. Proof of Concept Provide direct links to all referenced code in GitHub. A...

maxSupply in esLBR.sol is wrong

Lines of code Vulnerability details Impact Proof of Concept As mentioned in the docs in line 6 in esLBR.sol contract , the maximum supply will be 55 million . - The maximum amount that can be minted through the esLBRMinter contract is 55 million. But the maximum supply is hardcoded 100 million in...

The ethlbrStakePool, which is used in LOC 155 in EUSDMiningIncentives.sol, has no function balanceOf()

Lines of code Vulnerability details Impact The EUSDMiningIncentives.sol in LOC 155 uint256 userStaked = IEUSDethlbrStakePool.balanceOfuser; calls balanceOf function of ethlbrStakePool. By asking one of the sponsors, the address of this pool was given as 0x857CC243b8494e13BdbAde27C25ef61c2e500fda...

Token transfer is not handled properly in stakerewardV2pool.sol.

Lines of code Vulnerability details Impact Token transfer is not handled properly in stakerewardV2pool.sol. Many stakingtokens return a bool as transfer success , best practice is receiving the output as a boolean and revert the transaction if it is false. If it is not handled properly then it ma...

Keepers are allowed to use the full EUSD balance of any provider to liquidate funds

Lines of code Vulnerability details Impact Keepers are allowed to use the full EUSD balance of any provider to liquidate funds. Normally, the keeper should only be allowed to use max of the amount that the provider approves to LybraStETHVault. But the check only checks if the provider gives an...

users can pay the fees without burning the amount in their balances

Lines of code Vulnerability details Impact users can set the amount in the repay function to the amount that is equal to his fee and in this case the users can pay the fee without burning the amount in their balancesthe caller set himself as provider and onBehlaf in the same time. more details in...

Voting Delay set to 1 block, would not allow users enough time to buy tokens, or delegate their votes before the voting starts

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. With a voting delay set to 1 block, users would not have enough time to buy tokens, or delegate their votes. Proof of Concept Provide direct links to all referenced code in GitHub. Add screenshots, logs...

[H] Users can withdraw more tokens than they have staked

Lines of code Vulnerability details Impact Users can withdraw more tokens than they have staked from the contract. In stakerewardV2pool, there is no check to stop a user from withdrawing more tokens than they have staked. The tokens are simply subtracted from the user's balance and from the total...

Wrong validation when setting BadCollateralRatio

Lines of code Vulnerability details Impact Setting of BadCollateralRatio has a slight bug //@audit-issue bug here, should be - 1e19 function setBadCollateralRatioaddress pool, uint256 newRatio external onlyRoleDAO requirenewRatio = 130 1e18 && newRatio = 160 1e18, "eUSD vault safe...

quorumReached does not account for forVotes

Lines of code Vulnerability details Impact quorumReached does not account for forVotes. Proof of Concept The supportVodes mapping of the ProposalExtraData struct consists of three values: forVotes, againstVotes and abstainVotes respectively on keys 0, 1 and 2. The function: function...

Reward distribution logic of the ProtocolRewardsPool and EUSDMiningIncentives contracts are fundamentally wrong, resulting in excess rewards for users

Lines of code Vulnerability details Impact The reward distribution logic of the ProtocolRewardsPool and EUSDMiningIncentives contracts effectively allow a user to mint much more rewards than they should be allowed to. This is possible because, unlike a true implementation of the synthetix staking...

Proposal remains open to votes for only 3 blocks instead of 7 days

Lines of code Vulnerability details Impact LybraGovernance contract only allows to vote during the first 3 blocks after the snapshot is taken. Assuming it takes roughly 12 seconds per 1 block on Ethereum, it is only 36 seconds to decide and vote for a proposal. This would be too fast for a regula...

_quorumReached does not add all votes

Lines of code Vulnerability details Impact quorumReached is a function that checks if the Amount of votes already cast passes the threshold limit. But the function does not add all votes //@audit-issue quorum reached does not add all votes function quorumReacheduint256 proposalId internal view...

The function will not work properly on Optimism due to use of block.number

Lines of code Vulnerability details Impact On Optimism, the block.number is not a reliable source of timing information and the time between each block is also different from Ethereum. This is because each transaction on L2 is placed in a separate block and blocks are not produce at a constant...

Getting exchange rate function is wrong

Lines of code Vulnerability details Impact Unmatched function for getting the exchange rate can lead to being unable to mint PeUSD when depositing ETH into Rocket Pool. Proof of Concept The interface used in LybraRETHVault.sol for getting the exchange rate does not match the target contract RETH...

First user can drain funds from staking contract

Lines of code Vulnerability details Impact If the first user locks an extremely small amount of tokens 1 wei, he can manipulate the reward that is supposed to receive. After locking a small amount, he can unlock it before the second user interacts with the contract. See PoC for more details. Note...

User with bad collateralization ratio less than 125 cent can bypass super liquidation

Lines of code Vulnerability details Impact Users with a bad collateralization ratio such as less than 1251e15 can bypass super liquidation by just getting liquidated normally with the help of malicious liquidators/keepers where they might lose at most only 50% of their deposited collateral instea...

In LybraStETHVault.sol (LybraEUSDVaultBase.sol) a user could rigid redeem an amount more than their deposited collateral when the collateral ratio of the user goes below 100% even if they have been super-liquidated.

Lines of code Vulnerability details Impact If the collateral ratio of a user goes below 100%, the user would be able to redeem all of their eUSD for a collateral amount greater than their depositedAssetuser even after they have been super-liquidated. For eg, let us say we have a user X. Now, in...

stETHs rebase profit stealing

Lines of code Vulnerability details Description It's possible with flashloan from AAVE to capture a big shares amount of eUSD, after each stETH rebase exploiter will buy excessive income, which leads to eUSD rebase due to shares burning, so the exploiter will have most of burned eUSD because they...

Invalid Access Control Modifiers

Lines of code Vulnerability details Impact The LybraConfigurator is the contract in charge of all core functionality in the Lybra ecosystem. However, the modifiers checks here are invalid. So anybody could call any function in the protocol. All funds could be stolen and governance overturned Proo...

A Dutch trade could end up with an unintended lower closing price

Lines of code Vulnerability details Impact notTradingPausedOrFrozen that is turned on and off during an open Dutch trade could have the auction closed with a lower price depending on the timimg, leading to lesser capability to boost the Rtoken and/or stRSR exchange rates as well as a weakened...

The broker should not be fully disabled by GnosisTrade.reportViolation

Lines of code Vulnerability details Impact GnosisTrade and DutchTrade are two separate auction systems where the failing of either system should not affect the other one. The current design will have Broker.sol disabled when reportViolation is invoked by GnosisTrade.settle if the auction's cleari...

Lack of deep validation

Lines of code Vulnerability details Impact The validate functions are just checking the parameters type without checking any further information Proof of Concept They are just trying to cast the value with i.TYPE and check if there is an error. There is no further validations e. g...

There is no deadline for swaps

Lines of code Vulnerability details Impact If the receiver that is specified in the IBC callback doesn't have enough tokens for interacting with the Canto network defaults at 4 CANTO, then the middleware is going to swap the tokens for some CANTO tokens on the Canto network and convert the rest t...

Lack of input validation

Lines of code Vulnerability details Impact There is no input sanitizer implemented for the transfertypes.FungibleTokenPacketData data variable. Proof of Concept After "unmarshaling" the packet, which checks if there is an error, it is used right away without further checking the fields inside it,...

Bypass check with one non-standard denom

Lines of code Vulnerability details Impact Wrong conditional when checking for non-standard denoms Proof of Concept The conditional is used to sanitize if the denom1 and denom2 are indeed standardDenom see the error in the next line. However, the condition can be bypassed with one of them being...

users being overcharged or not receiving the full amount of coins as they expected caused by the incorrect calculation of the amount of coins bought

Lines of code Vulnerability details Impact in the GetInputPrice function there a line inputAmtWithFee := inputAmt.Mulsdk.NewIntFromBigIntdeltaFee.BigInt tat make a problem so here we have in that line in the GetInputPrice function, the sdk.NewIntFromBigInt function it's takes the big.Int as an...

Slippage protection minOut autoSwapThreshold is not effective when swapping the token

Lines of code Vulnerability details Impact In the current model, the minimum output minOut amount for the auto-swap is set to match the autoSwapThreshold, which is fixed at 4 CANTO. This configuration might result in potential market risks due to fluctuations in the value of CANTO, potentially...

User with canto balance under the treshold will receive 4 canto for every transaction wich will be included in a block

Lines of code Vulnerability details Impact User, who decided to send several different tokens in the canto network at the same time and who has canto balance under the threshold, will receive 4 canto for every transaction which satisfies other onboarding conditions token type, tokens amount, in...

On OnRecvPacket, TradeInputForExactOutput is called with all the amount of the transferred coin as a maximum which is not safe.

Lines of code Vulnerability details Impact In OnRecvPacket IBC receive callback, coinswapKeeper.TradeInputForExactOutput is called to swap from transferredCoin to standardDenom i.e. canto. TradeInputForExactOutput func takes the input as max amount of the token to be paid. This is not safe for th...

Canto pool could be drained.

Lines of code Vulnerability details Impact It was written that there a limit for 10 USDC /10 USDT /0.01 ETH, which currently equals to 10 USDT/ 10 USDC/ 18 USDT almost. These limits are for 4 Canto. Which means code accepts the Canto price at max: 2,5 USDC or equavalent. It is also written in the...

The calculateWithExactInput uses the same state's values for all transactions in the block

Lines of code Vulnerability details Impact The calculateWithExactInput uses the same state's values for all transactions. So all checks which should regulate swapped amounts will be broken. It can be a case of asset loss if there will be a significant amount of transactions in one block. Proof of...

Default coin spend limit was set wrong for ETH

Lines of code Vulnerability details Impact It is stated in the README that some spend limit are configured for the swaps. This is a security precaution to avoid spending too much tokens for the default 4 CANTO tokens in order to onboard the users if their balance is less than 4 tokens. As a...

Arbitrary parameters

Lines of code Vulnerability details Impact There is no way to check that the sequence parameter is indeed a correct one Proof of Concept It is being passed straight to a function which modifies the KVStore's pools, thus it could be any value due to not being checked e. g. it could be 0,...

Incorrect setting of EthIBCDenom invalidates risk management limits

Lines of code Vulnerability details Impact In the documentation, it is stated that: For risk management purposes, a swap will fail if the input coin amount exceeds a pre-defined limit 10 USDC, 10 USDT, 0.01 ETH or if the swap amount limit is not defined. However, in the code it defined as:...

Coinswap::Types::Params have a bad configuration for ETH max swap amount

Lines of code Vulnerability details Impact There is an error in the code regarding the maximum a user can spend for the 4 Canto swap to minimize risk of slippage. While the documentation claim it to be 0.01 ETH, in the code it is defined as 0.1 ETH, which is a 10x value increase and significant...

Pre-defined limit is different from the spec.

Lines of code Vulnerability details Impact In the spec, the pre-defined limit of ETH is 0.01 ETHs. But the actual limit in the code is not 0.01 ETH which could result in misleading. Proof of Concept In the spec, it said that the pre-defined limit of ETH is 0.01 ETHs For risk management purposes, ...

Doesn’t have proper slippage control.

Lines of code Vulnerability details Impact For risk management purposes, a swap will fail if the input coin amount exceeds a predefined limit. But it is not a slippage control. It doesn’t consider how many Canto a user wants to swap for. It is possible that the user will swap the token at a very...

GetStandardDenom at CreatePool might panic on unchecked nil

Lines of code Vulnerability details Impact A panic might occur when calling CreatePool and stop the app Proof of Concept here we can see CreatePool is creating new struct pool which call k,GetStandardDenom as value for StandardDenom key. now lets check GetStandardDenom body: func k Keeper...

D

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. Proof of Concept Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept. Tools Used Recommended Mitigation Steps Assessed...

The last error in swap.go#swapCoins() was not handled correctly.

Lines of code Vulnerability details Impact If the last statement of the swapCoins function returns an error, the swap is only half completed, i.e. only the user's assets are deducted transferred to the pool, but the user's bought assets are not sent to the user, resulting in a loss of the user's...

Lack of deadline parameter when executing swaps

Lines of code Vulnerability details Impact Deadline is not checked. The transaction may stay unexecuted for a long time, resulting in unfavourable trade when the transaction is finally executed. Proof of Concept The function OnRecvPacket is used to help users outside of Canto onboard seamlessly...

Users potentially cannot have Canto token swapped automatically when bridging assets to the Canto Network

Lines of code Vulnerability details Impact If the field AutoSwapThreshold is set to zero value, the logic that compares standardCoinBalance to the autoSwapThreshold always evaluates to false so there isn't any swap operation from bridged asset to Canto token for users. Therefore, the purpose of t...