Beanstalk: The Finale

Summary

Beanstalk's BeanL1ReceiverFacet uses a hardcoded bridge address, making it incompatible with potential L2 chains where Beanstalk might be deployed if the specified address does not exist on those chains. This could result in a situation where users' Beans are burned without receiving their migrated tokens.

Vulnerability Details

Take a look at https://github.com/Cyfrin/2024-05-beanstalk-the-finale/blob/8c8710df547f7d7c5dd82c5381eb6b34532e4484/protocol/contracts/beanstalk/migration/BeanL1RecieverFacet.sol#L31-L44

This function is used when attempting to migrate any amount of Beans to L2, i.e it's called in the instance below where the amount of beans are minted to the receiver, https://github.com/Cyfrin/2024-05-beanstalk-the-finale/blob/8c8710df547f7d7c5dd82c5381eb6b34532e4484/protocol/contracts/beanstalk/migration/BeanL2MigrationFacet.sol#L43-L57

Problem however is that it makes a query and requires that the msg.sender == address(BRIDGE). Now from here we can see that the bridge address has been hardcoded as 0x4200000000000000000000000000000000000007 but going to this EVM tool for reading contracts: https://www.contractreader.io we can see that the 0x4200000000000000000000000000000000000007 contract is non-existent on most of the EVM compatible L2 chains, which would mean that all attempts at receiving the migrated Beans would always revert here. Now keep in mind that before this function is called, the users tokens are already burnt here.

Impact

If the DAO deploys to a chain that the 0x4200000000000000000000000000000000000007 contract is non-existent then all users that attempt migrating their beans are just going to have it burnt for 0, considering they can never receive their migration.

Tools Used

Manual review

Recommendations

Consider passing in the bridge address during deployment instead of hardcoding it.