Ancient Tangelo Canary
Medium
function burn(address receiverOfUnderlying, uint256 yTokenAmount, uint256 underlyingTokenAmount) external onlyLendingPool nonReentrant { _burn(msg.sender, yTokenAmount); IERC20(underlyingAsset).safeTransfer(receiverOfUnderlying, underlyingTokenAmount); }
Attack Scenario The burn function burns yTokenAmount from msg.sender, but it transfers underlyingTokenAmount to receiverOfUnderlying. There is no check that underlyingTokenAmount corresponds to yTokenAmount at a 1:1 ratio (or any expected exchange rate). The lendingPool (or an attacker who controls it) can burn 1 yToken but withdraw an arbitrary amount of the underlying asset. This could lead to an imbalance in the protocol’s reserves, draining underlyingAsset unfairly.
Example Exploit
Assume a user deposits 1,000 DAI into the lending pool and receives 1,000 yDAI. If the lending pool is compromised or misconfigured, an attacker can call:
burn(attackerAddress, 1, 1_000_000); This would:
Burn only 1 yDAI. Transfer 1,000,000 DAI to the attacker. The protocol loses all its reserves, leading to insolvency.
as mentioned in document yToken Simple ERC20 which starts at 1:1 rate with underlying and increases in value
https://github.com/sherlock-audit/2025-02-yieldoor/blob/main/yieldoor/src/yToken.sol#L47
none
none
none
There is a security issue in the burn function that can be exploited to drain underlying assets.
No response
function burn(address receiverOfUnderlying, uint256 yTokenAmount, uint256 underlyingTokenAmount) external onlyLendingPool nonReentrant { @>> require(yTokenAmount == underlyingTokenAmount, "yToken/underlying mismatch");
_burn(msg.sender, yTokenAmount);
IERC20(underlyingAsset).safeTransfer(receiverOfUnderlying, underlyingTokenAmount);
}