The _claimRewards function in TokeAutoEthStrategy.sol incorrectly sends TOKE reward tokens directly to the MYT vault address instead of to the strategy contract itself. Since the MYT vault only handles WETH shares and has no mechanism to recover or process TOKE tokens, these rewards become permanently stuck and unrecoverable.
The vulnerable function is publicly callable without access control, allowing anyone to trigger this loss at any time.
The function calls getReward with address(MYT) as the recipient parameter, which causes the Tokemak rewarder to send TOKE tokens to the MYT vault contract. The MYT vault (a Morpho V2 Vault) expects only WETH as its underlying asset and has no functionality to handle or recover alternative tokens like TOKE.
Furthermore, the public claimRewards function has inadequate access control, only checking killSwitch status but allowing any address to call it.
Impact
This vulnerability results in permanent freezing of unclaimed yield. TOKE rewards earned from staking autoETH shares in the Tokemak rewarder represent unclaimed yield that belongs to strategy depositors. When these rewards are sent to the MYT vault, they become permanently inaccessible because the MYT vault only accounts for its underlying WETH asset in totalAssets calculations and has no rescue mechanism for non-underlying tokens.
The economic impact scales with the strategy's TVL and the TOKE reward APY. For example, with $1M TVL earning 5% APY in TOKE rewards, approximately $50,000 worth of TOKE would be permanently frozen annually. Any attacker can execute this attack at zero cost by simply calling the public claimRewards function, making it a viable griefing vector that causes continuous value loss to protocol users.
This qualifies as permanent freezing of unclaimed yield under the HIGH severity category because the TOKE rewards are yield meant for depositors but become permanently inaccessible when sent to an incompatible contract.
Risk Breakdown
Difficulty to Exploit: TRIVIAL
The attack requires a single function call with no prerequisites, capital requirements, or special permissions. The attacker does not need to be a strategy depositor or have any tokens. They simply call claimRewards() on the strategy contract and the rewards are immediately sent to the wrong address where they become stuck forever.
Recommendation
Modify _claimRewards to send TOKE tokens to the strategy contract itself, then implement logic to either swap them to WETH or distribute them appropriately. The corrected implementation should be:
Additionally, restrict claimRewards access to whitelisted allocators or strategy owner to prevent griefing attacks.