Collateralization ratio manipulation can cause a denial of service

Lines of code Vulnerability details Impact Stablecoin redeeming and profit accruing in the SavingsVest contract can be blocked when the collateralization ratio has overflown. Proof of Concept The mitigation recommended in 31 and implemented by the sponsor in this commit doesn't resolve the root...

Payable functions using delegatecall inside a loop

Lines of code Vulnerability details Impact The use of delegatecall within a loop, in the context of a payable function, can lead to the repeated crediting of the msg.value amount, potentially causing unexpected behavior or loss of funds. Proof of Concept contract DelegatecallInLoop is Multicall...

Potential Reentrancy in onlyAdmin modifier

Lines of code Vulnerability details The vulnerability lies in the AdminMultisigBase contract, in the onlyAdmin modifier. The onlyAdmin modifier does not prevent reentrancy, which can lead to a potential reentrancy vulnerability. The vulnerable part of the code: modifier onlyAdmin uint256 adminEpo...

onlyProxy MODIFIER CAN BE BYPASSED BY A MALICIOUS PROXY CONTRACT AND CAN PUSH THE IMPLEMENTATION CONTRACT INTO AN UNDESIRABLE STATE

Lines of code Vulnerability details Impact The Upgradeable.onlyProxy modifier is used to ensure that a function can only be called by the proxy and can not be directly called in the Upgradeable.sol contract. The onlyProxy modifier implementation is as follows: modifier onlyProxy // Prevent setup...

M-07 Unmitigated

Lines of code Vulnerability details Original Issue code-423n4/2023-06-angle-findings8 Details This issue shows users may get fewer tokens than expected when the collateral list order changes. As mitigation, it recommends checking the length of minAmountsOut and ts.collateralList as well as the...

Gas refunds are returned to the wrong address, leading to loss of funds for the payer

Lines of code Vulnerability details Impact To pay for cross-chain messages/calls, a user/third-party service must pay a reasonable fee in this case using the native token. However, often times a user will overpay to ensure that there is an adequate buffer for their tx to successfully succeed in...

Upgraded Q -> 2 from #392 [1689707598962]

Judge has assessed an item in Issue 392 as 2 risk. The relevant finding follows: 4 - The liquidator can be frontrunned while is depositing prizeTokens to the prizePool The liquidator should introduce prizeTokens to the prizePool before he calls the Vault.liquidate function. The problem is that a...

Attacker can brick redemptions by donating a small amount

Lines of code Vulnerability details Impact While the fix properly fixes the issue of collateralization ratio overflows that can no longer occurs, it enables DoS attacks on the redemption mechanism: Issue description Consider the example that was already provided code-423n4/2023-06-angle-findings9...

M-04 Unmitigated

Lines of code Vulnerability details While the fix improves the APR estimation for the case that is described in the finding, it significantly worsens it for other scenarios which may happen in practice when we assume underlying staking protocols with relatively constant APRs. For instance, consid...

Upgraded Q -> 2 from #93 [1689707967381]

Judge has assessed an item in Issue 93 as 2 risk. The relevant finding follows: L-01 - no check on the deployedVaults mapping in the VaultFactory can lead to duplicate vaults being created Mitigation - add an if check to not recreate the same vault: ifdeployedVaultsvault revert.... --- The text w...

Guardian can brick SavingsVest contract accidentally

Lines of code Vulnerability details Impact The fix to M-06 introduces a new vulnerability, as it turns a missing validation that previously was recoverable i.e., only a minor thing into an irrecoverable error, resulting in a permanent loss of funds. Proof of Concept Consider the scenario where th...

Upgraded Q -> 2 from #422 [1689707351452]

Judge has assessed an item in Issue 422 as 2 risk. The relevant finding follows: 01 In the function PrizePool.setDrawManager, anyone can frontrun it and become the drawManager Reading the documentation of the Prize Pool contract, the following is specified: The Prize Pool allows a 'draw manager'...

M-07 Unmitigated

Lines of code Vulnerability details The fix addresses the scenarios when collaterals are removed between the crafting of the minAmountsOut list and the submission of the transaction. Then, we will have amounts.length minAmountOuts.length, meaning that the following line causes a revert: if...

CONFIGURING ALLOWANCE TO ZERO FOR THE _previousLiquidationPair CAN BE FRONT RUN

Lines of code Vulnerability details Impact The Vault.setLiquidationPair is used to change the liquidationPair address to a new address. In the process it sets the allowance of the previousLiquidationPair to zero as shown below: if previousLiquidationPair != address0...

Unrestricted Name and Symbol Modification in LSP7 and LSP8 Digital Assets

Lines of code Vulnerability details I HAVE ALREADY SUBMITTED THIS ISSUE HOWEVER I MESSED UP THE LINKS FOR IT. CAN YOU PLEASE DISREGARD THE PREVIOUS SUBMISSION? Impact The owner of a contract in LSP8IdentifiableDigitalAsset and LSP7DigitalAsset can arbitrarily change the name and symbol of a token...

LSP8 and LSP9's ERC-165 interface ID differs from their specification

Lines of code Vulnerability details Bug Description According to LSP7's specification, the ERC-165 interface ID for LSP7 token contracts should be 0x5fcaac27: ERC165 interface id: 0x5fcaac27 However, INTERFACEIDLSP7 has a different value in the code: LSP7Constants.solL4-L5 // --- ERC165 interface...

Avoid using the same ERC-165 interface ID for URDs and their callers

Lines of code Vulnerability details Bug Description Contracts that implement the LSP-1 standard include INTERFACEIDLSP1 in their supportsInterface function. This means that they have a universalReceiver function that calls a Universal Receiver Delegate URD, such as LSP1UniversalReceiverDelegateUP...

The liquidate function lets the caller mint amountOut tokens without providing any

Lines of code Vulnerability details Impact Ther are a lot of check to ensure the parameters of the liquidate function are correct. However, it does not checki for amountIn to NOT be 0, thus it lets the caller proceed and mint amountOut tokens to account without providing any Proof of Concept...

Failed transfer with low level call could be overlooked

Lines of code Vulnerability details Impact Transfers may fail silently. Proof of Concept According to the Solidity docs: "The low-level functions call, delegatecall and staticcall return true as their first return value if the account called is non-existent, as part of the design of the EVM...

balanceOf method can be manipulate to liquidated vault

Lines of code Vulnerability details Impact Deriving price from balanceOf can be manipulated to liquidate vault see example Attacker can provide ERC20 token to the vaultAsset and mint vault shares. The deposited tokens will then be withdrawn with having same shares in the vault. The shares then wi...

deposit function does not check for the maxMint amount.

Lines of code Vulnerability details Impact It is theoretically possible for the deposit amount to mint shares more than the maxMint amount Proof of Concept The deposit function has a check for maxDeposit and reverts if the deposit value is more than maxuint96. But, it does not check the shares to...

TwabLib::getTwabBetween can return innacurate balances if _startTime and _endTime aren't safely bounded

Lines of code Vulnerability details M-01 TwabLib::getTwabBetween can return innacurate balances if startTime and endTime aren't safely bounded Vulnerability details Here's the documentation of the get TwabLib::getTwabBetween function : File: twab-controller\src\libraries\TwabLib.sol 278: / 279:...

Users might lose their balances when they set delegates

Lines of code Vulnerability details Impact Undelegated users will lose their balances if they set delegate to themselves. Proof of Concept A User can set a delegate and the delegated balance of the user will be accounted on the delegate's delegated balance in the TWAB controller. The internal...

tx.origin may be removed in future and its usage is not recommended

Lines of code Vulnerability details Impact There is a chance that tx.origin will be removed from the Ethereum protocol in the future, so code that uses tx.origin must be avoid for the authentication purpose. There is also some EIPs being proposed for change/remove of tx.origin. ethereum/EIPs637 I...

Depositors might lose funds due to the lack of zero share check

Lines of code Vulnerability details Impact Depositors might lose funds due to the lack of checking whether the shares to be minted is equal to zero. When this happens, the assets will be deposited into the vault, but the depositors will receive zero shares. This is independent from the initial...

Anyone can mint to themselves type(uint96).max if _isVaultCollateralized() returns true

Lines of code Vulnerability details Impact There is no check that ensures the caller to mint is a trusted one. Moreover, there is a flaw which lets anyone to mint typeuint96.max number of shares Proof of Concept First, the mint function does not implement any check for the caller to be someone wi...

The _currentExchangeRate of the Vault contract can't increase, and always be lower than or equal to _assetUnit

Lines of code Vulnerability details Impact The currentExchangeRate of the Vault contract can not increase, and always be lower than or equal to assetUnit. Therefore, when the vault is undercollateralized currentExchangeRate assetUnit, it can't be further collateralized. Proof of concept function...

Attacker can force users to delegate to SPONSORSHIP_ADDRESS

Lines of code Vulnerability details Impact An attacker can change the delegatee of a user who deposited into the vault to the SPONSORSHIPADDRESS address by calling one of the functions sponsor or sponsorWithPermit and giving the address of the user as receiver. The impact of this issue is that th...

Malicious claimer could arbitrage the prize-claiming functionality

Lines of code Vulnerability details Impact The feePerClaim is a user controlled parameter which tops at tierLiquidity.prizeSize for a given tier see here for that. That means the CLAIMER can set arbitrary fees for a given call to claimPrize to increase maliciously the collected fees with //...

Deposit transaction is prone to being front-run by bad actors.

Lines of code Vulnerability details Impact It is possible for an attacker to front-run a user's deposit transaction while transferring fewer amount of assets than the user and minting an equivalent amount of shares as the user could have. Proof of Concept The scenario described below is for the...

In LSP6SetDataModule.sol, Infinite loop in _verifyAllowedERC725YDataKeys()

Lines of code Vulnerability details Impact In verifyAllowedERC725YDataKeys there is a great possibility of an Infinite loop. This is because ++ii is an increment inside if condition. This can lead to excessive gas consumption, causing the Ethereum transaction to fail due to the gas limit Proof of...

Claim failure can result to loss of funds

Lines of code Vulnerability details Impact Caller will lose funds through gas fees when claim fails Proof of Concept The claimPrize function allows any caller to claim a prize by providing the necessary parameters: winner address of the winner, tier prize tier, prizeIndex prize index,...

_winningRandomNumber vartiable used in calculating if caller is winner can be read via web3.getStorageAt() and user can predict if he wins or not before hand

Lines of code Vulnerability details Impact the variable winningRandomNumber used in isWinner to calc if caller has won the tier can be read, and the calculation can be predicted. Proof of Concept that a variable is marked internal doesnt mean it cannot be read Tools Used vs code Recommended...

Inconsistencies When Using Inherited Functions

Lines of code https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC...

Incorrect distribution of shares and liquidity as a result of total number of shares not equaling 100

Lines of code Vulnerability details Impact If the shares are not properly validated and do not add up to 100, there will be an imbalance in the distribution of funds resulting in loss of funds or locked funds that cannot be accessed or distributed correctly. Proof of Concept The constructor of th...

Yield fee can be stolen

Lines of code Vulnerability details Impact The yieldFeeRecipient can claim some of the fees earned in the vault by calling mintYieldFee. The function has no access control so anyone can call the function and claim the yield fee for themselves. Proof of Concept In the below test an attacker Alice...

isTimeSafe and isTimeRangeSafe not implemented in the functions getBalanceAt and getTwabBetween

Lines of code Vulnerability details Impact The Natspec of both getBalanceAt and getTwabBetween functions indicates that they should implement the functions isTimeSafe and isTimeRangeSafe respectively to ensure that the queried timestamps are safe, but both functions don't implement them which can...

Pending owner can be the wrong recipient of ownership

Lines of code Vulnerability details Impact An attacker can call the acceptOwnership function with their address as the pending owner before the legitimate pending owner has a chance to call the function Proof of Concept The transferOwnership function allows the current owner to set a pending owne...

Malicious yield vault owners can manipulate the interaction between the vault and yield vault

Lines of code Vulnerability details Impact Malicious yield vault owners can steal depositor's assets. Proof of Concept yieldVault is the Address of the ERC4626 vault in which assets are deposited to generate yield. After tokens are deposited into the vault, the deposit function of yieldVault is...

The owner of a LSP0ERC725Account can become the owner again after renouncing ownership

Lines of code Vulnerability details Bug Description The renounceOwnership function allows the owner of a LSP0ERC725Account to renounce ownership through a two-step process. When renounceOwnership is first called, renounceOwnershipStartedAt is set to block.number to indicate that the process has...

No access control on mintYieldFee

Lines of code Vulnerability details Impact Lack of access-control allows anyone to mint the yield fee to himself. Proof of Concept Vault.mintYieldFee does not restrict the recipient yield fees: function mintYieldFeeuint256 shares, address recipient external requireVaultCollateralized; if shares...

Incorrect Interface ID for LSP14

Lines of code Vulnerability details Impact Contracts that use typeILSP14Ownable2Step.interfaceId, such as when implementing IERC165.supportsInterface, will use a value different from the current standard. Proof of Concept The interface ID of LSP14 is stated to be 0x94be5999. However, the interfac...

Allowing delegate call with msg.value in executeBatch() is dangerous

Lines of code Vulnerability details Bug Description ERC725XCore's execute function allows four types of operations: 1. CALL for normal calls 2. DELEGATECALL 3. CREATE/CREATE2 for contract deployment 4. STATICCALL The executeBatch function simply calls execute in a loop to perform multiple calls i...

Possible centralization issue in PrizePool.closeDraw

Lines of code Vulnerability details The winning random number is chosen by DrawManager, which will lead to centralization risk. Despite haventt really deep dive in codebase of this issue, but if DrawManager ,can somehow calculate which random number can make their controlled address is winner wit...

Allowed calls in LSP6KeyManager doesn't allow calls with empty calldata

Lines of code Vulnerability details Bug Description Whenever a controller attempts to call a LSP0 account's execute function without the relevant SUPER permissions, LSP6ExecuteModule will check that the call is one of the whitelisted allowed calls. If the controller is trying to perform a call wi...

Using supportsERC165InterfaceUnchecked() might break LSP functionality for certain contracts

Lines of code Vulnerability details Bug Description Throughout the codebase, the protocol uses the supportsERC165InterfaceUnchecked function from Openzeppelin's ERC165Checker.sol to check for the support of ERC-165 interface IDs. However, supportsERC165InterfaceUnchecked only checks if the call t...

Incorrect Interface ID for LSP0

Lines of code Vulnerability details Impact The interface ID stated for LSP0 in LSP0Constants.sol and LIP-0 is 0x3e89ad98, which will affect related logics. Proof of Concept According to LIP-0, this ID is derived from the XOR of the following: selector of batchCalls IDs of the following standards:...

Sponsor function allows voiding some elses chance to win

Lines of code Vulnerability details Impact Anyone can delegate someone elses balance to the sponsorship address, increasing their own likelihood of winning, while voiding the victims chance. Proof of Concept The issue is in the call-chain starting with Vault.sponsor: //Vault function sponsoruint2...

Two-step ownership transfer process in LSP0ERC725AccountCore can be bypassed

Lines of code Vulnerability details Bug Description To transfer ownership of the LSP0ERC725AccountCore contract, the owner has to call transferOwnership to nominate a pending owner. Afterwards, the pending owner must call acceptOwnership to become the new owner. When called by the owner,...

Users with DEPLOY permission can grief each other through CREATE2

Lines of code Vulnerability details Bug Description In ERC725XCore.sol, the deployCreate2 function uses Openzeppelin's Create2.deploy to deploy new contracts: ERC725XCore.solL253-L267 function deployCreate2 uint256 value, bytes memory creationCode internal virtual returns bytes memory newContract...