On 3 April, CertiK was alerted to an incident involving a malicious validator front running multiple Miner Extractable Value (MEV) bots leading to a loss of just over $25 million. This is the largest incident targeting these automated trading bots to date. This incident was due to a malicious validator front-running the MEV bot's back-run transaction.
MEV stands for "miner extractable value" or "maximal extractable value." Miners – or more accurately described as validators now that Ethereum has switched to Proof of Stake (PoS) – have the power to sequence transactions within blocks. This ability to reorder transactions means they can front-run users' transactions submitted to the mempool. One of the most common forms of MEV is called a sandwich attack, where a validator sees that someone is trying to buy a certain asset so they insert a transaction of their own ahead of the original transaction, buy the asset, and then sell it to the original purchaser at a markup. They have extracted value from this user, who is often none the wiser that they didn't get the price they were expecting. MEV bots who repeat these kinds of transactions multiple times can make large profits.
A sandwich attack consists of four elements:
The strategy works because the MEV bot has created an artificial arbitrage opportunity by manipulating the price of an asset and selling at a higher price. The goal of the MEV bot is to “sandwich” the buy order in a front-run and back run transaction.
Image: Sandwich attack illustration. Source: CertiK
In Ethereum block 16964664 eight MEV transactions were exploited by a rogue validator that was created on 15 March, 2023, by externally owned address (EOA) 0x687A9. This wallet received the required 32 ETH by withdrawing the funds from Aztec, a DeFi privacy provider. This rogue validator was introduced into the Flashbot network, which is designed to ensure that no front running is possible.
Image: The transaction showing the malicious validator being set up. Source: Etherscan
However, a vulnerability in the MEV-boost-relay allowed a malicious validator to re-bundle transactions allowing them to intercept part of the MEVs sandwich strategy. In a MEV sandwich strategy the bot monitors a chain's mempool for profitable trading opportunities. When an opportunity is identified the MEV will front run a user’s transaction by paying a higher gas fee to ensure their trade is conducted before the users. Once the user’s transaction is executed the MEV conducts a back-run within the same block to extract profit. In order to back run, the MEV bot pays less gas fee than the user. It was this back-run that was replaced by the malicious validator. Essentially, when submitting a block the proposer is not able to see the contents of the block they’re signing until it’s been signed. However, the vulnerability would return all transactions to the validator if the block was signed correctly which allowed the malicious validator to extract assets from the MEV bots.
In total, approximately $25 million dollars was stolen from five MEV bots making this one of the largest incidents impacting MEV bots that CertiK has identified. Exploits on MEV bots are rare with only six identified over the last 12 months with an overall loss of $27.5 million, with 92% related to this incident alone.
In this incident, the stolen funds are held in three EOAs at the time of writing with the amount stolen broken down below:
Image: Breakdown of assets. Source: Etherscan
This incident was made possible due to a bug in the MEV-boost-relay of Flashbot. The mev-boost-relay contained a function that wouldn’t throw away any errors and just checks that the producer, which in this case is the malicious validator, has signed the block correctly.
Image: vulnerability in mev-boost-relay: Source GitHub
The PublishBlock() function won’t throw away any errors and will return the payload to the validator. The consequence of this is that the malicious validator is able to see and resubmit the transaction bundle to the network by modifying it, and allowing them to order the transactions in a way that extracts the funds from the MEV bots.
Thankfully, this bug has now been patched and MEV bots are no longer vulnerable to this specific attack vector. The remediation ensures that the block is correctly published on-chain before all the transactions are sent back to the validator.
Image: Patch in MEV-boost-relay: Source GitHub
The malicious validator began by submitting an invalid block that was signed correctly. Because of the vulnerability noted above, the transactions within the block were revealed which allowed the malicious validator to see the transactions and re-bundle to claim the assets from the MEV bots.
The malicious validator conducted 8 front-running transactions on 5 MEV bots within block 16964664.
Image: Malicious transactions targeting the MEV bot. Source: Etherscan
The attack began with the malicious validator sending the relay false information which was then broadcast on the consensus layer. Once the information is broadcast to the consensus layer, the relay will return an error. At this stage, the relay shouldn’t have based detailed transactions information to the validator, but did due to the vulnerability mentioned above. Now that the malicious validator has detailed transaction information, they can build their own block and insert their front running transaction in front of the MEV bots initial transaction. From there, the attacker broadcasts to the consensus layer with the correct information and produces the block.
Attacks on MEV bots are relatively rare with a total of 6 exploits identified by CertiK over the last 12 months with this incident being by far the largest exploit on MEV bots. Additionally, this exploit is the second largest attack that we have seen this year in terms of funds lost to a malicious actor. Fortunately, the bug that was exploited in this incident has now been patched, meaning that this attack vector is no longer open. This means that traders are still subject to sandwich attacks in the future by MEV bots and will almost certainly continue to be a contentious issue in the Web3 community.