Summary

The Beanstalk protocol has a migration mechanism from a seasons-based to a stems-based silo system for managing user deposits. This migration process involves transferring user deposits from the old system to the new one, recalculating stalk and seed balances, and updating storage structures.

Rebasing tokens, such as stETH (Lido Staked Ether), have a unique characteristic where the token balance of holders can change over time without any direct user action. This is typically due to staking rewards being distributed or losses being socialized across all token holders. For stETH specifically, the balance of stETH tokens in a user's wallet increases over time to represent the accrual of staking rewards on the Ethereum network.

Vulnerability Details

The current migration process appears to assume that token balances remain constant throughout the migration procedure. This assumption does not hold for rebasing tokens like stETH. The migration function _mowAndMigrate processes deposits sequentially, potentially allowing time for a rebase event to occur mid-migration.

The removeDepositFromAccount function removes a specific amount from the old deposit system, and later addDepositToAccount adds this same amount to the new system. However, if a rebase occurs between these operations for a token like stETH, the actual balance available could have changed.

Impact

• If a positive rebase occurs (balance increases), the user could lose out on the additional tokens that were credited during the migration process.

• If a negative rebase occurs (balance decreases, though uncommon for stETH), the contract might attempt to transfer more tokens than are actually available, potentially causing the migration to fail or leave the contract in an inconsistent state.

Tools Used

Manual

Recommendations

• Implement specific handling logic for known rebasing tokens.

• This could involve using token-specific interfaces to query for "shares" instead of balances for tokens like stETH.