Future Beanstalk Native DEX (aka Liquidity Wells) is Susceptible to a Newly Identified Exploitable MEV Strategy
(Out of scope)
A newly identified exploitable MEV strategy whereby an attacker could potentially steal all initial deposits to the under development Beanstalk native DEX (aka Liquidity Wells), as sent through the public mempool.
(Out of scope)
The Beanstalk Farms development team is currently working on the future Beanstalk Native DEX, otherwise referred to as Liquidity Wells: https://github.com/BeanstalkFarms/Beanstalk/pull/83
Liquidity Wells, as described to the Beanstalk user community by the Beanstalk Farms development team in various community engagements thus far, will allow for liquidity pools in the Silo to be hosted on Beanstalk natively.
Liquidity Wells will be permissionless, enabling any user to create a new BEAN pool trading against another token. As such, users will be able to have a yield bearing stable ERC-20 token representing their shares of the pool.
The BEAN:ETH pool will debut with the launch of Liquidity Wells, expected at the end of Q4 2022 or sometime in early 2023, per recent development estimates conveyed by the Beanstalk Farms team.
As described, Liquidity Wells may be susceptible to a newly identified attack vector vis-a-vis an exploitable MEV strategy. This exploitable attack vector was recently identified on 10/14/22 for Bunni Protocol by Riley Holterhus, a smart contract security expert; as explained by Riley, "This is a variant of a well-known attack, the key difference being the attacker provides liquidity directly to the protocol instead of directly transferring some tokens." Although Bunni Protocol was audited, their auditor explained that they "didn't consider minting liquidity to the contract itself..." (see "References" section below).
Consider a scenario where an innocent user seeks to permissionlessly provide liquidity to a Liquidity Well pool that has never been deposited in before. As detailed by Riley, a malicious MEV searcher can backrun this initial user's transaction with a withdraw call. Since the attacker will then own 100% of the ERC-20 supply corresponding to the pool, they will be given 100% of the protocol's liquidity, including the initial deposit from the innocent user. Since the ERC-20 supply would zero out after this, the attacker can repeat this exploit.
Liquidity Wells, upon their debut, will house all Silo liquidity for Beanstalk Protocol, and will debut the BEAN:ETH pool. This liquidity figure currently equates to nearly $30M, per the present assets in the BEAN:3CRV Pool.
Beanstalk implements the EIP-2535 Diamond structure, which means it can have multiple upgradable parts. As LP pools will be hosted on the Beanstalk native DEX, user funds can be stolen if there is an exploit in Beanstalk as long as Beanstalk holds the LP tokens in the Silo.
Difficulty to Exploit: Easy to Relatively Easy
Weakness: Although Liquidity Wells are not yet live, they are currently in development and will be a foundational feature of the Beanstalk Protocol once they debut, since all Silo assets will be migrated to this new Beanstalk native DEX. Beanstalk's bug bounty page on ImmuneFi notes that "the current implementation and any further updates to the contracts are considered in-scope."
CVSS2 Score: 4 (although an exploit such as this that can result in the direct theft of user funds would be considered a "Critical" exploit, I noted the score to correspond with a "High" exploit since Liquidity Wells are still under development).
As suggested by Riley Holterhus, the smart contract security expert that initially alerted the DeFi community on 10/14/22 about this potential attack vector with regards to Bunni Protocol, "In order to fix this bug, it is recommended to require a minimum number of shares be minted in the first deposit. If the attacker minted 10^18 wei instead of 1 wei at the start, then they would need to supply 10^18 times as much liquidity as the [initial] user, which is infeasible...Another good idea is to revert in the case of minting zero shares because that should never happen anyways."
Twitter thread from Riley Holterhus on 10/14/22 outlining this newly identified attack vector: https://twitter.com/rileyholterhus/status/1581028470699982848
Blog post from Riley Holterhus offering more detail about the attack vector and how to address it: https://www.rileyholterhus.com/writing/bunni
Thread from Bunni Protocol auditor detailing that this was an attack vector they did not consider: https://twitter.com/sjkelleyjr/status/1581081068471390208?s=20&t=0AZCgsxV9S7fstw0btfeNQ
Proof of concept
Refer to the blog post by Riley Holterhus, in which he details how such an attack scenario would play out: https://www.rileyholterhus.com/writing/bunni
Hi, Immunefi has reviewed this vulnerability report and decided to close since being out of scope for Beanstalk bug bounty program.
- claimed impact by the whitehat
is not in scopefor the bug bounty program
- claimed asset by the whitehat
is not in scopefor the bug bounty program
- PoC has been submitted to the project
- claimed severity is in scope for the bug bounty program
Since this bug bounty program does not require Immunefi's triaging, note that Immunefi does not:
- check if whitehat's claims are factually correct
- check PoC to understand the validity
- assess the submission's severity
These activities are the project's responsibility.
The project will now be automatically subscribed and receive a report of the closed submission and can evaluate if they are interested in re-opening it. However, note that they are not under any obligation to do so.