Notional will burn the shares to mint at a lower share value due to volatility or forced MEV. To protect from these, the slippage used is 0. That is the root cause and redeeming less amounts out than deserving is the impact.
Vulnerability Detail
_redeemPT below calls SY.redeem with 0 as minTokenOut. If you look at SYBase.redeem, there is a slippage check if amountTokenOut < minTokenOut. So, if you input 0 as min out then it is not slippage protected and prone to MEV attacks.
Flow 2 has internal overrides with custom implementation at _initiateSYWithdraw between initiateWithdraw -> _initiateWithdrawImpl
Flow 1 is onlyNotional, but flow 2 can be called by any notional account
It doesn't matter even if you use private mempool to redeem, the redemption is subjected to slippage loss. There is no guarantee that slippage will be zero or 100%, because its possible if the minimum amount input is 0, which is the case here. Due to high volatility, the share price may go too low, and we end up burning our shares at low prices leading to lower redemption amounts.
And in flow 2, if a private mempool is not used, the it is subjected to MEV. Someone will redeem by burning the shares, then backrun Notional account's redemption, by depositing to mint shares at a much lower price.
Notional will burn the shares to mint at a lower share value due to volatility or forced MEV. To protect from these, the slippage used is 0. That is the root cause and redeeming less amounts out than deserving is the impact.
High impact due to loss of funds and likelihood is always due to hardcoded 0 slippage amount.
Ironsidesec
High
_redeemPT
uses 0 slippageSummary
Notional will burn the shares to mint at a lower share value due to volatility or forced MEV. To protect from these, the slippage used is 0. That is the root cause and redeeming less amounts out than deserving is the impact.
Vulnerability Detail
_redeemPT
below callsSY.redeem
with 0 asminTokenOut
. If you look atSYBase.redeem
, there is a slippage check ifamountTokenOut < minTokenOut
. So, if you input 0 as min out then it is not slippage protected and prone to MEV attacks._redeemPT
is called in 3 flows,Flow 2 has internal overrides with custom implementation at _initiateSYWithdraw between
initiateWithdraw
->_initiateWithdrawImpl
Flow 1 is
onlyNotional
, but flow 2 can be called by any notionalaccount
It doesn't matter even if you use private mempool to redeem, the redemption is subjected to slippage loss. There is no guarantee that slippage will be zero or 100%, because its possible if the minimum amount input is 0, which is the case here. Due to high volatility, the share price may go too low, and we end up burning our shares at low prices leading to lower redemption amounts. And in flow 2, if a private mempool is not used, the it is subjected to MEV. Someone will redeem by burning the shares, then backrun Notional account's redemption, by depositing to mint shares at a much lower price.https://github.com/sherlock-audit/2024-06-leveraged-vaults/blob/14d3eaf0445c251c52c86ce88a84a3f5b9dfad94/leveraged-vaults-private/contracts/vaults/staking/protocols/PendlePrincipalToken.sol#L137
https://github.com/pendle-finance/pendle-core-v2-public/blob/97b1b9708478b389f9540d71816c7894aab6bb77/contracts/core/StandardizedYield/SYBase.sol#L76
Impact
Notional will burn the shares to mint at a lower share value due to volatility or forced MEV. To protect from these, the slippage used is 0. That is the root cause and redeeming less amounts out than deserving is the impact. High impact due to loss of funds and likelihood is always due to hardcoded 0 slippage amount.
Code Snippet
https://github.com/sherlock-audit/2024-06-leveraged-vaults/blob/14d3eaf0445c251c52c86ce88a84a3f5b9dfad94/leveraged-vaults-private/contracts/vaults/staking/protocols/PendlePrincipalToken.sol#L137
https://github.com/pendle-finance/pendle-core-v2-public/blob/97b1b9708478b389f9540d71816c7894aab6bb77/contracts/core/StandardizedYield/SYBase.sol#L76
Tool used
Manual Review
Recommendation
https://github.com/sherlock-audit/2024-06-leveraged-vaults/blob/14d3eaf0445c251c52c86ce88a84a3f5b9dfad94/leveraged-vaults-private/contracts/vaults/staking/protocols/PendlePrincipalToken.sol#L137
Duplicate of #70