Full Report
On April 2nd, a malicious network participant within the Flashbots eco-system "stole" (lost profits) $20M from a MEV searcher by abusing a vulnerability in the mev-boost-relay implementation. When the patches were released, this led to instability within the network and many reorgs. mev-boot is a protocol designed by flashbots in order to mitigate the negative effects of Maximal Extractable Value (MEV) on the network. There are three main actors: Relays: Mutually trusted auctioneers that connect the two other parties. Builders: Entities who construct blocks in order to maximize MEV for themselves and the proposers. Proposers: An Ethereum Proof-of-Stake validator who is about to create a block. The ordering of an event for each block is as follows: A builder creates a block by looking at public and private orderflows. The builder submits the block to a relay. The relay validates that the block is valid (previous vulnerability lolz) and figures out how much to pay the proposer. The relayer sends a blinded header and a payment value to the proposer of the current slot. The proposer evaluates the bids they've received and signs the one with the highest payment. The proposer sends the signed header back to the relay. The blocker gets published by the relayer. The rewards are distributed as originally described. The relayer is a mutually trusted third party that facilitates an exchange to benefit everyone. It prevents builders/proposers from stealing funds. A fork choice rule is a function relating to reaching consensus on the state of the chain. In terms of time, the PoS system is broken down into 12 second increments called slots. A different set of nodes are assigned to vote on whether a block is legit or not for the head of the chain. At 4 seconds, the block is proposed. At 8 seconds the voting occurs. At 12 seconds, the next proposer publishes their block. If a block isn't proposed after 4 seconds, they will vote for a previously accepted head of the chain. Why would somebody do this? Letting MEV accumulate is worthwhile because of the amount of funds that can be gained from it, but slows down the network. How do we fix this problem of actors waiting and causing forks? Boosts! To minimize the amount of reorgs that occur, a fork-choice boost of 40% of the weight is given for a single slot for a single proposer. This prevents reorg balancing attacks. This allows the proposer to have more weight on the approval. Honest reorgs are the other solution. If there is an attestation weight below 20%, a proposer can forcibly reorder the blocks to prevent a fork on the chain. By doing this, the forks are less likely to occur but the proposers are able to wait for a better proposed block. An interesting post into the intricacies of MEV and the Flashbots protocol. I don't 100% understand everything here but watch direct adversaries attempt to make money without destroying the ecosystem is fascinating.
Analysis Summary
# Incident Report: mev-boost-relay Unbundling & Network Instability
## Executive Summary
On April 2nd, 2023, a malicious validator exploited a vulnerability in the `mev-boost-relay` implementation to "unbundle" blocks, resulting in the theft of approximately $20M from MEV searchers. The subsequent emergency patches released to secure the protocol introduced unexpected timing latencies, leading to a spike in block reorgs and temporary Ethereum network instability on April 6th.
## Incident Details
- **Discovery Date:** April 2nd, 2023
- **Incident Date:** April 2nd – April 6th, 2023
- **Affected Organization:** Ethereum Network / Flashbots Ecosystem
- **Sector:** Blockchain / Decentralized Finance (DeFi)
- **Geography:** Global / Decentralized
## Timeline of Events
### Initial Access
- **Date/Time:** April 2nd, 2023
- **Vector:** Exploitation of a vulnerability in the relay validation logic.
- **Details:** A malicious proposer/validator exploited a bug where the relay failed to properly verify block validity before revealing contents, or allowing for an "unbundling" where the proposer could see the MEV opportunity without successfully committing the original block.
### Lateral Movement
- **N/A:** The attack was not a network intrusion but a protocol-level exploitation of the Proof-of-Stake (PoS) auction mechanism.
### Data Exfiltration/Impact
- **April 2nd:** Malicious actor extracted $20M in profits by front-running/stealing MEV searcher transactions after gaining access to blinded block content.
### Detection & Response
- **April 3rd:** Flashbots released a post-mortem and identified the `mev-boost-relay` bug.
- **April 3rd–5th:** Five security patches were released across the ecosystem to harden the relay and beacon nodes.
- **April 6th:** The network experienced significant instability and frequent "reorgs" (reorganizations) as a side effect of the new security checks adding latency to the 12-second slot window.
## Attack Methodology
- **Initial Access:** Exploit of `mev-boost-relay` vulnerability.
- **Persistence:** Not applicable (one-time exploit per slot).
- **Defense Evasion:** Use of "blinded" auction mechanisms to hide malicious intent until the moment of block proposal.
- **Impact:** Financial theft via "unbundling" (separating the MEV value from the original builder's block to claim it for the proposer).
## Impact Assessment
- **Financial:** $20M USD stolen from MEV searchers.
- **Data Breach:** None (transactional transparency is inherent to the blockchain).
- **Operational:** High; increased reorg rate on April 6th slowed block production and reduced settlement assurances.
- **Reputational:** Moderate; highlighted risks in the "trusted" relay model of the Flashbots ecosystem.
## Indicators of Compromise
- **Behavioral indicators:** Proposers signing blinded headers but failing to successfully propagate the original builder's transactions; high rates of "equivocation" or missed slots by specific validator indices.
## Response Actions
- **Containment:** Emergency patches to `mev-boost-relay` to ensure proposer commitment before data release.
- **Eradication:** Logic updates to Beacon Nodes to handle the timing of block propagation more strictly.
- **Recovery:** Implementation of "Proposer Boost" (40% weight) and "Honest Reorg" logic to stabilize the chain following the patch-induced latency.
## Lessons Learned
- **Latency is a Security Perimeter:** In PoS, a few milliseconds of delay in block propagation can be exploited or cause network-wide instability.
- **The "Trusted" Relay Weakness:** Relying on a single point of truth (the relay) creates a critical failure point.
- **Unintended Consequences:** Fixes for financial exploits can inadvertently trigger consensus-level instability if they add processing overhead to time-sensitive slots.
## Recommendations
- **Enshrined-PBS (ePBS):** Move the MEV-boost functionality directly into the Ethereum consensus layer to remove third-party relay risk.
- **Client Diversity:** Increase the diversity of relay implementations to avoid single-point-of-failure bugs.
- **Timing Adjustments:** Re-evaluate sub-slot timings (e.g., moving attestation deadlines from 4s to 6s) to account for modern network latency.
- **Enhanced Testing:** Implement more rigorous "Hive" and spec tests specifically targeting latency-induced edge cases in the fork-choice rule.