contract has the tendency to mint more tokens than it actually has

Lines of code Vulnerability details Impact If the contract does not have enough esLBR tokens to mint and transfer as rewards, users will not be able to claim their rewards even if they have earned them. Proof of Concept There is no check to ensure that the contract's balance of esLBR tokens is...

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

An attacker can burn shares of other users by calling executeFlashloan()

Lines of code Vulnerability details The executeFlashloan in PeUSDMainnetStableVision.sol allows users to execute flash loans but the problem is that the receiver doesnt have to be the msg.sender so an attacker can do 2 things: 1. Execute other users flash loans 2. If a user is a smart contract th...

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

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

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

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

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

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

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

[H] Eth remains stuck in contract due to reversion in convertToPeUSD

Lines of code Vulnerability details Impact ETH sent with this call will not be refunded to the caller upon revert. Proof of Concept Due to a discrepancy in the convertToPeUSD function where the call to mintVault implemenation from transferFrom is non-existent, the subsequent call to...

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

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

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

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

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

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

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

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

Wrong proposalThreshold amount in LybraGovernance.sol

Lines of code Vulnerability details Impact The proposal can be created with only 100000 esLBR delegated instead of 10000000. Proof of Concept According to LybraV2Docs, a proposal can only be created if the sender has at least 10 million esLBR tokens delegated to his address to meet the proposal...

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

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

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

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

_voteSucceeded and proposals give opposite result

Lines of code Vulnerability details Impact In the LybraGovernance contract, the voteSucceeded function returns true if supportVotes1 supportVotes0. At the same time in the proposals function supportVotes0 is returned as forVotes and supportVotes1 is returned as againstVotes. This could suggest,...

Users with bad collateralization ratio from either rebase/nonrebasevault can bypassliquidation

Lines of code Vulnerability details Impact users with an unsafe collateralization ratio who are supposed to be liquidated can manipulate the rigidRedemption feature to bypass the liquidation. From the code above its noted that being a rigidRedemption provider one can can put their collateral amou...

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

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

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

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

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

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

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

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

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

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

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

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

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

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 token pair existence

Lines of code Vulnerability details Impact There is no check that ensures the token pair does exists. Proof of Concept he code assumes that if a token pair ID is not registered or if the token pair is not enabled, the conversion process will be skipped. However, there is no explicit check or...

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

Add check to disallow creation of Standard Denomination pool

Lines of code Vulnerability details Impact CreatePool does not check if the counterpartyDenom is a Standard Denomination. This can lead to creation of pools where the StandardDenom and the CounterpartyDenom are the same. Code reference // CreatePool create a liquidity that saves relevant...

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

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

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

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