Beanstalk Part 3

Summary

When addUnripeToken() is called by the admin, it ignores to account for any existing token balance in the current s.u[unripeToken].underlyingToken before updating the underlyingToken to a new underlyingToken. Such existing balance is migrated from the old to the new underlyingToken. This will result in a incorrect calculation in getPenalizedUnderlying function when it is calculated chop.

Vulnerability Details

The addUnripeToken function in the UnripeFacet contract allows the addition of an unripe token with its corresponding underlying token and Merkle root. However, if there is already an existing underlying token associated with the unripe token, this function will override the existing underlying token without any checks. This can result in the new unripe token incorrectly assuming the non-zero balance of the previous underlying token. This can lead to a loss of asset tracking.

So the addUnripeToken function does not check if the provided unripeToken is already present in the s.u mapping. If the underlyingToken is changed, the balance of the previous underlying token is affected. This leads to incorrect calculations when redeeming assets, as the balance associated with the unripe token will not accurately reflect its true value.

Impact

The function getPenalizedUnderlying calculates the redeem amount of underlying tokens based on the balance of the underlying token associated with the unripe token. If the underlying token is incorrectly overridden, the redeem calculation will be incorrect.

Tools Used

Manual Review

Recommendations