A user could drain collateral from LybraStETHVault.sol even if they have redeemed all their eUSD for their deposited collateral

Lines of code Vulnerability details Impact Suppose a user deposits certain Ether and mints eUSD. The user collects mining rewards for sometime assuming that the their earnings are not claimable by others. After sometime, the user redeems all their eUSD for StETH. Now, even after redemption, the...

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

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

Exploiter can avoid negative Lido rebases stealing funds from EUSD vaults

Lines of code Vulnerability details Description Lybra keeps the exact amount of collateral as deposited ignoring any lido rebases. That allows malicious users to sandwich negative rebase transactions with depositing and withdrawing their stETH saving the exact amount as before negative rebase. Th...

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

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

[M] Mining rewards are not distributed to users

Lines of code Vulnerability details Impact Expected mining rewards in distributeRewards are not distributed due to a revert in purchaseOtherEarnings. Proof of Concept A missing mintVault implementation in transferFrom will inevitably cause a revert in purchaseOtherEarnings. This means expected...

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

executeFlashloan() doesn't pass/authenticate the initiator address

Lines of code Vulnerability details Impact In PeUSDMainnetStableVision.sol executeFlashloan. File: contracts/lybra/token/PeUSDMainnetStableVision.sol 129 function executeFlashloanFlashBorrower receiver, uint256 eusdAmount, bytes calldata data public payable 130 uint256 shareAmount =...

[H] Users can lose funds if they call depositEtherToMint

Lines of code Vulnerability details Impact Due to only an interface implementation of function submit in Lido contract, users will lose funds due to non-existent implementation. Proof of Concept The comments in the code suggest that when users deposit ETH, it should be directly deposited into the...

flashloan stealing staking reward

Lines of code Vulnerability details Impact The report reveals a vulnerability where a flashloan can be used to steal staking rewards. The provided proof of concept demonstrates the issue, where a user can take advantage of the earned rewards calculation using the spot balance. By flashloaning a...

proposals view function returns wrong voting results

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. Even though, the votes are calculated correctly, the proposals view function returns wrong voting results returning forVotes results as againstVotes amount. This would negatively impact the users...

_voteSucceeded check is invalid

Lines of code Vulnerability details Impact //@audit-issue wrong check vote succeeded is when 0 1 function voteSucceededuint256 proposalId internal view override returns bool return proposalDataproposalId.supportVotes1 proposalDataproposalId.supportVotes0; voteSucceeded is a function that checks i...

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

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

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

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

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

Missing require statements in onlyRole/checkRole modifiers

Lines of code Vulnerability details In LybraConfigurator.sol, there are two modifiers, checkOnlyRole and checkRole from GovernanceTimelock, designed to verify whether the msg.sender is authorized. However, these modifiers lack "require" statements to enforce the condition that the returned boolea...

The LybraRETHVault.depositEtherToMint doesn't keep record of user's ether deposits which results in loss for the user.

Lines of code Vulnerability details Impact High: User will lose his deposited ether. Proof of Concept The collateralAsset address variable which is used in LybraPeUSDVaultBase is assumed to be stETH token address Now the depositEtherToMint function from contract LybraRETHVault.sol which inherits...

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

[M] Hardcoded address will not remain consistent across other chains

Lines of code Vulnerability details Impact The hardcoded address for the LBR token will not remain consistent across other chains, such as Polygon, Avalanche, Arbitrum and BSC for example. IEUSD0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2.balanceOfethlbrLpToken Proof of Concept Hardcoding the addre...

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

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

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

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

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

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

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

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

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

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

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

The Swap action will always fail if the value of the deposited IBC asset is less than the value of autoSwapThreshold Canto

Lines of code Vulnerability details Impact The Swap action will always fail if the value of the deposited IBC asset the value of autoSwapThreshold Canto. This is not a bug, but it's very inconvenient for users and makes the goal of the onboarding module fail. Let's asssume that: 1 Canto = 0.1 USD...

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

An error could lead to coins not being returned to user

Lines of code Vulnerability details Impact The function swapCoins does check that SendCoins does receive them correctly here but not when sending them to the user here Proof of Concept If there is an error returning the swapped coins to the user, they will remain locked. There is no history of...

GetAllPools could panic at iterator loop

Lines of code Vulnerability details Impact A panic could occur in GetAllPools and stop the program Proof of Concept there is no check for pool value if nil or not before calling MustUnmarshal which could lead to a panic issue in the program func k Keeper GetAllPoolsctx sdk.Context pools types.Poo...

Lack of checks for non-zero values

Lines of code Vulnerability details Impact Lack of propper parameter validation Proof of Concept The GetPoolByLptDenom function takes lptDenom as an input parameter and uses it right away as an argument to retrieve a pool from the KVStore. However, if it is empty or invalid, the function will...

Token pairs that are not whitelisted can be created as a pool

Lines of code Vulnerability details Class Medium Impact In the docs: Only token pairs on the whitelist can be created as a pool. Pool creation fails if the token pair is not on the whitelist. However, there is no logic that prevents from creating non-whitelisted pairs. The check is only happening...

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

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

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

Missing store revert in case of swap error can lead to loss of funds

Lines of code Vulnerability details Impact The module is expected to have no state changes in case a swap failed, and continue to the conversion phase. It was implemented by swallowing the error with a log and continuing with the flow erc20 conversion, etc. This is the relevant code section:...

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

Missing slippage protection leads to potential sandwich of small transfers or blocking the swap feature

Lines of code Vulnerability details Impact The swap module is invoked with a default of coinswaptypes.InputCoin: transferredCoin, Address: recipient.String, coinswaptypes.OutputCoin: swapCoins, Address: recipient.String. The swap module makes sure that in tokens of the swap are limitted to...

AutoSwapThreshold field is not checked for exceeding MaxAutoSwapThreshold constant

Lines of code Vulnerability details Impact validateAutoSwapThreshold function has a problem that does not check the AutoSwapThreshold field is less than or equal to the MaxAutoSwapThreshold constant, this can caused that a malicious user could set the AutoSwapThreshold field to a value that is...

packet.DestinationChannel IS CHECKED AGAINST THE WhitelistedChannels, BUT packet.SourceChannel SHOULD BE CHECKED INSTEAD, AS PER THE PROTOCOL DESIGN REQUIREMENTS

Lines of code Vulnerability details Impact In the ibccallbacks.OnRecvPacket function, the Source Channel of the transferred packet is required to be checked against the WhitelistedChannels of the module. If the Source Channel of the packet is not in the WhitelistedChannels list then the auto swap...

The validation of the source channel is performed incorrectly

Lines of code Vulnerability details Impact There is a potential risk of unauthorized sources sending assets to the Canto Network and automatically swapping transferred tokens for Canto tokens. Proof of Concept When bootstrapping Canto Network, node operators config channel ID for the onboarding...

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

Potential risk of using swappedAmount in case of swap error

Lines of code Vulnerability details Impact In case the swap operation failed, the module should continue as is with the erc20 conversion and finish the IBC transfer. This is the relevant part of the code that swallows the error: swappedAmount, err = k.coinswapKeeper.TradeInputForExactOutputctx,...