Full Report
In web3, a random user is selected to be the block creator. In order to maximize profit, this is split into three users: builder, relayer and validator. Builder is the trader willing to pay for the transaction block ordering. The relayer is a trusted auctioneer and identifies the highest bid from the builder. The validator is the creator of the block. The process of MEV is a player vs. player (PvP) contest. There are thousands of trading bots that see the same data as everyone else but only one can win. Unlike traditional finance, which competes on speed, Web3 competes on price alone because block times on ETH are 12 seconds long. Of course, different chains have different requirements. A lot of builders send bids to the relayer and the validator chooses the highest bid's setup to construct the block with the most popular market being Flashbots. When a trader submits a transaction to the relay, the relay recalculates the top bid; also known as the current winner. When setting the top bid, the users bid is retrieved from the redis cache and then user is written as the winning address and bid amount. To set the bid, there's a separate API that sets the cache key of the bid. There's a classic time of check vs. time of use (TOCTOU) issue here. If you set the bid to be very high, the code tries to update the highest bidder. While doing this, the bid amount can be reset to a very low value. This is a tight race window so it must be spammed over and over again. This results in winning the auction without paying anything! To fix the issue, the Redis COPY command was used instead. Given the impact of this, it was weird that it was only a $5K payout. A good takeaway is that concurrency is hard to get correct and should always be considered.
Analysis Summary
# Vulnerability: Flashbots Relay Race Condition (Bait & Switch)
## CVE Details
- **CVE ID**: Not explicitly assigned (Common in bespoke blockchain infrastructure patches)
- **CVSS Score**: Estimated 7.5 - 8.1 (High)
- **CWE**: CWE-367: Time-of-Check to Time-of-Use (TOCTOU) Race Condition
## Affected Systems
- **Products**: Flashbots Relay (and potentially other MEV-Boost compatible relays)
- **Versions**: Found and patched in 2023 versions of Flashbots relay software.
- **Configurations**: Systems utilizing Redis for high-speed caching of builder bids and payloads without atomic operations/locking.
## Vulnerability Description
The vulnerability is a classic **Time-of-Check vs. Time-of-Use (TOCTOU)** flaw located in the `UpdateTopBid` function of the relay’s Redis datastore logic.
In the MEV (Maximal Extractable Value) auction process:
1. **The Check**: The Relay queries Redis (`HGetAll`) to identify the highest bidder (e.g., "Builder X" bidding 100 ETH).
2. **The Window**: A minute timing gap exists between the verification of the bid and the retrieval of the associated transaction payload.
3. **The Use**: The Relay queries Redis again (`HGet`) to fetch the current payload for "Builder X."
An attacker can exploit this gap by submitting a "Bait" bid (high value) to pass the check, then immediately sending a "Switch" bid (zero value) to overwrite the payload before the Relay performs the second query. The Relay then commits the zero-value bid as the winner.
## Exploitation
- **Status**: PoC discovered and disclosed via bug bounty (2023); patched.
- **Complexity**: High (Requires precise timing/spamming within a millisecond window during the 12-second block time).
- **Attack Vector**: Network (API-based submission to the Relay).
## Impact
- **Confidentiality**: Low/None.
- **Integrity**: High (The integrity of the auction winner's payment is compromised).
- **Availability**: Low (Spamming the relay might impact performance).
- **Financial**: Critical. Allows traders to win blocks and secure arbitrage profits without paying the obligated bid to validators, potentially siphoning millions in value.
## Remediation
### Patches
- The Flashbots team implemented a fix by transitioning from a multi-step check-then-act process to an atomic operation using the **Redis `COPY` command**. This ensures that the valid payload identified during the check is moved to the "winning slot" instantaneously, closing the race window.
### Workarounds
- Implement strict mutex locking on the `UpdateTopBid` function (though this may impact performance in high-frequency trading environments).
- Validate that the bid amount retrieved in the "Use" phase matches the amount verified in the "Check" phase before committing.
## Detection
- **Indicators of Compromise**: Monitoring logs for high-frequency updates to a single builder's bid within sub-millisecond intervals.
- **Detection Methods**: Auditing blockchain records for winning blocks where the actual validator payout (bid) is significantly lower than the simulated competitive market rate at that slot.
## References
- Mav Levin Security Research: [https://mavlevin.com/](https://mavlevin.com/)
- Flashbots Documentation: [https://docs.flashbots.net/](https://docs.flashbots.net/)
- Original Writeup: [https://mavlevin.com/2023/billion-dollar-bait-and-switch-exploiting-a-race-condition-in-blockchain-infrastructure](https://mavlevin.com/2023/billion-dollar-bait-and-switch-exploiting-a-race-condition-in-blockchain-infrastructure)