[M-01] Easily bypassing admins 'pause' for swivel

Lines of code Vulnerability details Impact Assuming admin decides to pause an external principle when it's dangerous, malicious or unprofitable, Bypassing the admins decision can result in loss of funds for the project. Proof of Concept The principals enum p is only used for unpausedp modifier, a...

[H-05] Not minting iPTs for lenders in several lend functions

Lines of code Vulnerability details Impact Using any of the lend function mentioned, will result in loss of funds to the lender - as the funds are transferred from them but no iPTs are sent back to them! Basically making lending via these external PTs unusable. Proof of Concept There is no mintin...

Principal token is not transferred

Lines of code Vulnerability details Impact When redeeming from APWine and Tempus here, the principal token is not transferred to the redeemer, so may be stuck on the lender contract. Proof of Concept Instead of Safe.transferFromIERC20u, lender, addressthis, amount; it should be...

Potential interests are not distributed fairly among the zcTokens holders, nor taken as a protocol fee, but will be frozen in the redeemer contract

Lines of code Vulnerability details function authRedeem address u, uint256 m, address f, address t, uint256 a public authorizedIMarketPlacemarketPlace.marketsu, m, 0 returns bool // Get the principal token for the given market IERC5095 pt = IERC5095IMarketPlacemarketPlace.marketsu, m, 0; // Make...

Redeemer.sol#redeem() the principal token from Notional can not be redeemed

Lines of code Vulnerability details int256 amount = IERC20principal.balanceOflender; // Transfer the principal token from the lender contract to here Safe.transferFromIERC20principal, lender, addressthis, amount; if p == uint8MarketPlace.Principals.Swivel // Redeems zc tokens to the sender's...

In Notional case Redeemer's redeem() will not do the position redeeming

Lines of code Vulnerability details Currently no actual redeeeming is done in Notional case as maxRedeem is a balance view function that doesn't close the position. This way one more operation, the redeeming itself, is now committed and in Notional case Redeemer's redeem doesn't perform anything,...

Lender.sol amountIn is used as returned for Pendle

Lines of code Vulnerability details uint256 returned; // Add the accumulated fees to the total uint256 fee = calculateFeea; feesu += fee; address memory path = new address; path0 = u; path1 = principal; // Swap on the Pendle Router using the provided market and params returned =...

Safe.approve may not work for USDT

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: The following function may fail and make USDT...

Unpaused modifier can be sidestepped in one of the lend functions.

Lines of code Vulnerability details Impact Suppose you tried to pause the lend function that is connected to Swivel. In that case, the attacker could sidestep it because there is no verification that the number input from the user corresponds with the desired input. Proof of Concept Let's say a b...

Staking.setCurvePool() doesn't approve allowance when changes CURVE_POOL.

Lines of code Vulnerability details Impact Staking.setCurvePool doesn't approve allowance when changes CURVEPOOL. It will affect when users exchange asset through CURVEPOOL. Proof of Concept When initialize the contract, Staking contract approves CURVEPOOL here. But when admin updates CURVEPOOL...

setCurvePool does not approve the new curve pool to transfer the TOKE_POOL token, making it unusable for its intended purpose.

Lines of code Vulnerability details Staking.solsetCurvePool File: Staking.sol 153: / 154: @notice sets the curve pool address 155: @param curvePool uint 156: / 157: function setCurvePooladdress curvePool external onlyOwner 158: CURVEPOOL = curvePool; 159: setToAndFromCurve; 160:...

User fund lose in addLiquidity() of LiquidityReserve by increasing (totalLockedValue / totalSupply()) to very large number by attacker

Lines of code Vulnerability details Impact Function addLiquidity suppose to do add Liquidity for the staking Token and receive lrToken in exchange. to calculate amount of IrToken codes uses this calculation: amountToMint = amount lrFoxSupply / totalLockedValue but it's possible for attacker to...

Staking.sol#stake() DoS by staking 1 wei for the recipient when warmUpPeriod > 0

Lines of code Vulnerability details if warmUpPeriod == 0 IYieldyYIELDYTOKEN.mintrecipient, amount; else // create a claim and mint tokens so a user can claim them once warm up has passed warmUpInforecipient = Claim amount: info.amount + amount, credits: info.credits +...

if attacker gets admin private key then he can drain all the tokens that Lender.sol contract holds

Lines of code Vulnerability details Impact if attacker gets admin private key then he can drain all the tokens that Lender.sol contract holds Recommended Mitigation Steps make it harder for admin to do this with some internal sec requirements --- The text was updated successfully, but these error...

Sense AMM address can be manipulated, allowing unlimited mint of principal tokens

Lines of code Vulnerability details Lender's lend for Sense uses ISensex.swapUnderlyingForPTs output to determine the Illuminate PT amount to be minted for the user. x is a user supplied and not verified address, which can be precooked by a malicious user to return any inflated amount, that will ...

Inconsistent balance when fee-on transfer tokens.

Lines of code Vulnerability details Impact There are ERC20 tokens that may make certain customizations to their ERC20 contracts. One type of these tokens is deflationary tokens that charge a certain fee for every transfer or transferFrom. Proof of...

[H-04] Some fees are locked on contract without ever being able to be collected

Lines of code Vulnerability details Proof of Concept The full amount a is transferFrom lender on L215 The amount - fee is invested on L219 and L229. Unlike other lend function, this one is missing crediting the project with the fees they entitled to. As a result, these fees cannot be collected vi...

Illuminate PT redeeming do not return underlying to a user

Lines of code Vulnerability details In the second step of two step redeeming process, the underlying funds should be located in the Redeemer contract as external system burned the shares the Redeemer obtained from the Lender contract and returned underlying to Redeemer. Then Redeemer's Illuminate...

Minting to user after funds deposit is now omitted in Lender's Swivel lend

Lines of code Vulnerability details Lender's Swivel version of lend pulls the underlying funds from the user, opens the necessary positions, but now fails to mint Illuminate PT for the user, so there will be no records for her investment and the corresponding funds aren't recoverable. Setting...

Upgraded Q -> H from 215 [1656255310294]

Judge has assessed an item in Issue 215 as High risk. The relevant finding follows: L-09 wfCashERC4626 contract does not conform to EIP4626 Description The wfCashERC4626 contract implements the EIP4626 standard EIP-4626: Tokenized Vault Standard. However, according to EIP4626, the below-mentioned...

Reentrancy vulnerabilities

Lines of code Vulnerability details Impact Reentrancy attacks can allow malicious actors to take over the control flow, and make...

Yieldy: WarmUp expiry can be prolonged by staking from somebody else

WarmUp expiry can be prolonged by staking from somebody else Staking.sol:406 Staking.sol:439-444 Staking.sol:691 Impact When warmUpPeriod is greater than 1, a third person can stake to the victim to prolong the warmUp expiry. The expiry prolongation also happens with cool down, although a third...

Transfer the principal token from the lender contract to here but actually transfer underlying token

Lines of code Vulnerability details Impact Transfer the principal token from the lender contract to here but actually transfer underlying token from lender to redeemer. Proof of Concept // Transfer the principal token from the lender contract to here Safe.transferFromIERC20u, lender, addressthis,...

Transfer the original underlying token back to the user but actually transfer from lender to redeemer

Lines of code Vulnerability details Impact Transfer the original underlying token back to the user but actually transfer from lender to redeemer. Underlying token may be locked forever and user may not receive their fund after redeeming. Proof of Concept // Transfer the original underlying token...

Redeemer.sol#redeem() can be called by anyone before maturity, which may lead to loss of user funds

Lines of code Vulnerability details function redeem uint8 p, address u, uint256 m public returns bool // Get the principal token that is being redeemed by the user address principal = IMarketPlacemarketPlace.marketsu, m, p; // Make sure we have the correct principal if p !=...

[M-02] transferring LESS funds from lender than needed

Lines of code Vulnerability details Impact Wrong accounting calculation may result in malfunctioning and loss of funds for the project. Proof of Concept As seen in the lines above, the amount transferred from the lender is after subtracting the fee he actually needs to pay On the other hand, the...

Deflationary/fee-on-transfer tokens are not supported

Lines of code Lender.solL215 Lender.solL337 Lender.solL398 Lender.solL456 Lender.solL521 Lender.solL564 Lender.solL617 Vulnerability details Impact When an amount of underlying tokens is sent to the Lender.sol contract during a lend, the actual amount gained by the contract might not be exactly t...

Fee on transfer tokens not supported

Lines of code Vulnerability details Impact Fee on transfer tokens would lead to sellers getting more PT than what the pool has received in underlying as the difference in balance is not accounted for, only the a input. This is also true for mintWithUnderlying as minters get more in relation to th...

Yield of LiquidityReserve can be stolen

Lines of code Vulnerability details Impact Using sandwich attacks and JIT Just-in-time liquidity, the yield of LiquidityReserve could be extracted for liquidity providers. Proof of Concept The yield of LiquidityReserve is distributed when a user calls instantUnstakeReserve in Staking. Then, in...

[M-04] Admin can lose control on the contract

Lines of code Vulnerability details Proof of Concept The setAdmin function is too loose, if no one have access to the address passed in this function, the whole project is stuck - cannot withdraw funds or fees, cannot create new markets, etc. Recommended Mitigation Steps Change setAdmin in favour...

instantUnstake function can be frontrunned with fee increase

Lines of code Vulnerability details Impact instantUnstake allows user to unstake their stakingToken for a fee paid to the liquidity providers. This fee could be changed up to 100% any moment by admin. Malicious admin could frontrun users instantUnstake transaction and set fee to any value using...

Forgot to mint Illuminate zcTokens for Element

Lines of code Vulnerability details function lend uint8 p, address u, uint256 m, uint256 a, uint256 r, uint256 d, address e, bytes32 i public unpausedp returns uint256 // Get the principal token for this market for element address principal = IMarketPlacemarketPlace.marketsu, m, p; // the element...

Inaccurate fee calculation

Lines of code Vulnerability details Impact The equation in the calculateFee function has a high degree of inaccuracy Solidity use integers, when divide an uint256 for other uint256 the divition take the floor number and ignore the decimal part In example: a = 1999 ETH feenominator = 1000 the retu...

Improper Upper Bound Definition on the Fee

Lines of code Vulnerability details Impact The feenominator does not have any upper or lower bounds. Values that are too large will lead to reversions in several critical functions or the platform user will lost all funds when paying the fee. Proof of Concept 1. Navigate to the following contract...

_storeRebase() is called with the wrong parameters

Lines of code Vulnerability details storeRebase's signature is as such: Yieldy.solstoreRebase File: Yieldy.sol 104: / 105: @notice emits event with data about rebase 106: @param previousCirculating uint 107: @param profit uint 108: @param epoch uint 109: / 110: function storeRebase 111: uint256...

instead of call() , transfer() is used to withdraw the ether

Lines of code Vulnerability details Impact To withdraw eth it uses transfer, this trnansaction will fail inevitably when : - The withdrwer smart contract does not implement a payable function. Withdrawer smart contract does implement a payable fallback which uses more than 2300 gas unit Thw...

Front running Staking can bypass warmUpPeriod

Lines of code Vulnerability details Impact Yieldy implements a warmUpPeriod to prevent new stakers from using freshly minted yieldy tokens in the Staking.sol contract. warmUpPeriod is not initialised in the contract initialisation therefore a user can frontrun when the onlyOwner calls...

Illuminate PT redeeming allows for burning from other accounts

Lines of code Vulnerability details Illuminate PT burns shares from a user supplied address account instead of user's account. With such a discrepancy a malicious user can burn all other's user shares by having the necessary shares on her balance, while burning them from everyone else. Setting th...

No minting done in the Element version of lend function, user funds are frozen within the system

Lines of code Vulnerability details Lender's Element lend transfers the funds from a user, opens the position with Element, but fails to mint a corresponding Illuminate position to a user. Setting severity to be high as there is no account of user investment is effectively created, so there is no...

DoS attack on claiming rewards can lead to user never being able to claim

Lines of code Vulnerability details Proof of Concept: the stake function can be called for a different recipient than msg.sender. Each time you stake tokens your warmUpInfo.expiry or the time when you are able to claim rewards grows by warmUpPeriod as is visible the last line here not the line wi...

removeAddress doesn't decrease the contracts.length

Lines of code Vulnerability details Impact The contracts length will always increase because the removeAddress function just deleting the value inside the array and never decrease the length by calling pop method. This can lead to Dos when calling functions that doing loop on contracts storage:...

Call to lend() function can be frontrunned with fee increase

Lines of code Vulnerability details Impact Malicious admin could frontrun users lend transaction anytime and set feenominator to any value using setFee and bigger fee than user expected. /// @notice sets the admin address /// @param a address of a new admin /// @return bool true if successful...

lender variable in is not the same as constructory and method in the construcotr ther is no check for address zero

Lines of code Vulnerability details Impact lender variable not the same as constructory and method its no check for address zero Recommended Mitigation Steps check for address zero in the constructor --- The text was updated successfully, but these errors were encountered: 😕 1 KenzoAgada reacted...

Rug vector for admin of Lender.sol who can max approve all principal tokens for any market without waiting the 3 days to themselves

Lines of code Vulnerability details Impact The admin of Lender.sol is authorized to call the function approve which will grant any address max approval over the principal tokens of a particular market. I assume that this functionality is used to approve the respective redeemer contracts used in...

griefing on claim()

Lines of code Vulnerability details Issue: griefing can happen if coolDownPeriod is 0 due to the fact that you can stake for someone else, whenever a stake happens, the expiry variable increases with coolDownPeriod. This can be done either by watching the mempool and frontrun a stake when someone...

Able to mint any amount of PT

Lines of code Lender.solL192-L235 Lender.solL486-L534 Lender.solL545-L589 Vulnerability details Impact Some of the lend functions do not validate addresses sent as input which could lead to a malicous user being able to mint more PT tokens than they should. Functions affect: Illuminate and Yield...

Yieldy._totalSupply has different upper bounds.

Lines of code Vulnerability details Impact Yieldy.totalSupply has different upper bounds. Yieldy.mint will revert when totalSupply is exactly same as MAXSUPPLY. Proof of Concept From L91-L98, we can see totalSupply can be same as MAXSUPPLY and I think "totalSupply = MAXSUPPLY" is reasonable also...

Upgraded Q -> H from 104 [1656255316696]

Judge has assessed an item in Issue 104 as High risk. The relevant finding follows: L02: Incompatibility with ERC-4626 Line References Description The EIP-4626 specification requires that totalAssets to NOT revert, but the current implementation does so in the underlying methods: int256...

Funds may be stuck when redeeming for Illuminate

Lines of code Vulnerability details Impact Funds may be stuck when redeeming for Illuminate. Proof of Concept Assuming the goal of calling redeem for Illuminate here is to redeem the Illuminate principal held by the lender or the redeemer, then there is an issue because the wrong balance is...

No support for fee on transfer tokens

Lines of code Vulnerability details Impact stake will revert for tokens that charge a fee on transfer. Proof of Concept Note: POC below assumes tokePoolContract.depositamount transfers part of Staking.sol balance to tokePoolContract. stake uses the amount as a reference for depositToTokemak and...