Relevant GitHub Links

https://github.com/Cyfrin/2024-05-beanstalk-the-finale/blob/8c8710df547f7d7c5dd82c5381eb6b34532e4484/protocol/contracts/beanstalk/init/reseed/L2/ReseedBarn.sol#L55

https://github.com/Cyfrin/2024-05-beanstalk-the-finale/blob/8c8710df547f7d7c5dd82c5381eb6b34532e4484/protocol/contracts/beanstalk/Diamond.sol#L26-L27

Summary

The codebase makes use of the CREATE function for deployment in multiple places, making it vulnerable to reorg attacks.

Vulnerability Details

There are two major places in which CREATE1 is used to being used for deployment. The first is upon diamond deployment, upon which the deployed address is used in the addDiamondFunctions function.

The second place is in the ReseedBarn contract during initializations, in which the fertilizer and its implementations are deployed.

Considering that the L1 contracts are to be deployed on Ethereum mainnet, while the L2 contracts, ReseedBarn will be deployed on potentially L2s as voted on by the DAO, the risk of reorg situations is greatly increased.

Ethereum experiences [reorgs](https://decrypt.co/101390/ethereum-beacon-chain-blockchain-reorg], so does Polygon, as seen in this case and in this case. Arbitrum and Optimistic rollups (including placeholder Base chain) also experience reorgs since if someone finds a fraud the blocks will be reverted, even though the user receives a confirmation.

If a malicious user sees that a potential victim has created a fertilizer and in the following block he tries to fund it, but due to the reorg occuring at in the same blocks, he can take advantage and front-run the init call. Thus, the fertilizer is created with the address in which the victim had initially sent funds. By doing so, he will steal victim's funds, because the address of the deployed contract would be the same one, before the reorg.

Impact

Potential loss of funds due to reorg situations.

Tools Used

Manual Review

Recommendations

Conduct deployments via CREATE2 with salt that inlcudes msg.sender.