Flashbots MEV Bot Attack on Ethereum: Vulnerability Analysis, Exploit Timeline, and Mitigation

The article begins by noting the growing importance of smart‑contract security in blockchain applications and introduces a series of case studies on common vulnerabilities, with this third installment focusing on a high‑value MEV bot attack.

Event recap : On 2023‑04‑03, multiple MEV bots were compromised in block 16964664, resulting in a loss of approximately $25.39 million across several tokens (WBTC, USDC, USDT, DAI, WETH). The attacker, a malicious validator, replaced eight transactions, causing five MEV bots to lose funds.

Background knowledge : MEV (Maximum Extractable Value) refers to profit extracted by reordering or censoring transactions. MEV bots automate this process, often executing sandwich attacks that front‑run and back‑run user trades to capture price differences.

Ethereum PBS protocol : In Proof‑of‑Stake Ethereum, the builder and proposer roles are separated by the Proposer‑Builder Separation (PBS) protocol, preventing proposers from seeing block contents before signing. However, a flaw in Flashbots’ mev_boost_relay module allowed block content to be exposed even when publishing failed.

Vulnerability analysis : The attacker exploited the relay’s failure to handle PublishBlock() errors. When a block broadcast failed, the relay still returned the block data, revealing private transaction details. The attacker then crafted a valid block that swapped the original sandwich‑attack transactions with ones that harvested the MEV bots’ funds.

// Publish the signed beacon block via beacon-node
func() {
    if api.ffDisableBlockPublishing {
        log.Info("publishing the block is disabled")
        return
    }
    signedBeaconBlock := SignedBlindedBeaconBlockToBeaconBlock(payload, getPayloadResp)
    _, _ = api.beaconClient.PublishBlock(signedBeaconBlock) // errors are logged inside
}()

Exploit process :

The attacker withdrew 32 ETH from Aztec to become a validator.

After staking, the validator was activated (epoch 187922) and later selected as proposer for block 16964664.

Using the relay flaw, the attacker learned the pending transactions and replaced the original sandwich‑attack trades with reverse‑arbitrage trades that drained the MEV bots’ WETH.

The malicious block, though initially illegal (parent_root and state_root set to zero), was accepted because the relay had already exposed the transaction data, eliminating the need to race the relayer.

The attack affected five MEV bots, each losing significant WETH holdings. Detailed transaction traces and token flow diagrams illustrate how the attacker first swapped 2,239.826 WETH for 8.541 BitDAO, then reversed the trade to capture the bots’ assets.

Post‑attack, the validator was penalized for violating proposal rules, and its identity can be inspected on beacon explorer links provided.

Mitigation : The fix involves proper error handling in the relay. After a failed block publish, the relay should log the error and abort without returning block contents.

// Publish the signed beacon block via beacon-node
signedBeaconBlock := SignedBlindedBeaconBlockToBeaconBlock(payload, getPayloadResp)
code, err := api.beaconClient.PublishBlock(signedBeaconBlock) // errors are logged inside
if err != nil {
    log.WithError(err).WithField("code", code).Error("failed to publish block")
    api.RespondError(w, http.StatusBadRequest, "failed to publish block")
    return
}

The article concludes that exposing private transaction pools poses severe security risks and that timely remediation of relay error handling is essential to protect MEV ecosystems.

References include Ethereum consensus documentation, Flashbots MEV‑Boost guides, and several investigative news articles.