Full Report
In April of 2023, a malicious proposer tricked the Ultrasound relay into revealing the contents of a block by committing an invalid block initially. This allowed for the attacker to perform an unbundling attack to reorder the transactions against the builder's MEV attempts to get a heavy profit of $50M. Troy found a variant of this attack on the Titan relay implementation. Running validators and building optimal MEV blocks are entirely different specializations. So, the validator (proposer) can outsource their block building to another entity called a builder. The relayer is an intermediary that can take multiple proposals (aka how much they will pay the validator to make the block how they want). The secrecy of the built block is of the utmost importance to the builder, as we learned with the 2023 attack. During a proposer's slot, it will request a payload from the relay. It will then sign and thereby commit to proposing this block without seeing the entire payload, which is called blinded. The proposer will then send the signed block back to get the relay to send back the unblinded block, revealing its contents. This blinding approach works because of duplicate block slashing. If the proposer signs the commitment, gets back the other block, and frontruns the original with their own malicious and unbundled block, then it will get slashed (lose funds) for doing this. To make this even harder, the relayer delays responses to line up with their proposal windows end in order to make it harder to perform unbundling attacks. Ethereum blocks contain a blob sidecar (additional blob information). When a Beacon Node receives this, it will reject it if the commitments do not correspond to the blob contents. The function validate_header_equality() verifies the contents of the signed execution payload match what the builder supplied but it does NOT check the KZG commitments. Since invalid KZG commitments can be provided, the block will be rejected when propagated but the relayer doesn't know this. So, when the block is returned, it can be unbundled when sent back to the proposer to do the same attack as from 2023. To fix this, the code now verifies that the builders and proposers have matching KZG commitments. Overall, an excellent blog post that is rich in context for those (like myself) unfamiliar with the MEV builder and proposer market.
Analysis Summary
# Vulnerability: Proposer Equivocation via Missing KZG Commitment Validation in Helix MEV Relay
## CVE Details
- CVE ID: Not explicitly provided in the text. (Likely a specific finding for Helix Relay, not a widely tracked CVE yet).
- CVSS Score: Not explicitly provided in the text. (Severity implied as High due to potential massive MEV profit theft).
- CWE: CWE-284 (Improper Access Control) or CWE-754 (Improper Neutralization of Special Elements) related to missing input validation.
## Affected Systems
- Products: Titan Relay implementation, specifically the **Helix MEV Relay**.
- Versions: Versions introduced supporting the Deneb hard fork lacked critical validation logic.
- Configurations: Any configuration where a trusted proposer could interact with the Helix Relay to request and receive unblinded blocks using a block proposal mechanism that relies on blinded block commitment signing.
## Vulnerability Description
Following the April 2023 incident where a malicious proposer tricked a relay into revealing a block's contents prematurely via an invalid block commitment, standard relays implemented safeguards, including verifying KZG commitments present in the proposal response.
The vulnerability in **Helix MEV Relay** (Titan's implementation) occurred because it *missed* this key validation step after upgrading for the Deneb hard fork.
1. **Blinded Commitment:** A proposer signs a "blinded" block header, committing to proposing the block without seeing its contents (especially MEV transactions).
2. **Relay Response:** The proposer sends this commitment to the relay to receive the "unblinded" block (containing the builder's confidential MEV transactions).
3. **The Flaw:** The missing validation in Helix meant that the proposer could submit a signed block header whose **KZG commitments did not match the actual blob contents** supplied by the builder.
4. **Exploitation:** Because the local validator node performs verification *before* broadcasting (which would reject the block due to invalid KZG commitments), the proposer could receive the unblinded, valuable block from the relay, then submit a different, malicious, unbundled block to the network.
5. **Result:** Since the relay was not checking KZG commitment integrity when returning the unblinded block, the proposer could safely equivocate, leak the builder's transaction ordering, perform an unbundling attack to reorder transactions against the builder's interests, and realize massive profits ($50M mentioned as the context of the precursor attack).
## Exploitation
- Status: The article describes a **variant** of a successful attack from April 2023. The mechanism was confirmed to be present in Helix, making **exploitation possible (or highly likely if exploited by a trusted proposer)**, though the article doesn't confirm if the Helix-specific variant had immediate success against Titan.
- Complexity: Assumed **Medium** (Requires understanding of MEV dynamics, proposer roles, and timing).
- Attack Vector: Network (Proposer communicating with the Relay).
## Impact
- Confidentiality: High (Premature leakage of sensitive builder transaction data).
- Integrity: High (Ability to reorder transactions against the builder’s intentions via unbundling).
- Availability: Low (The main impact is financial theft/manipulation, not service downtime, though premature block broadcasting could cause attestor issues).
## Remediation
### Patches
- The article notes that Flashbots upgraded its relay implementation to add a check on KZG commitment integrity. Specifically, the fix implemented across standard relays was to **verify that the builders and proposers have matching KZG commitments** upon block return.
- Specific Git commits or version numbers for the **Helix Relay patch** are not provided, only that the disclosure was made responsibly to Titan/Gattaca.
### Workarounds
- **If running a Beacon Node (e.g., Lighthouse):** Local verification done before broadcasting (`publishBlockV2` API check) *would have prevented untrusted proposers from receiving the block* if they attempted the attack, offering a layer of defense against immediate external gossip.
- **General Deterrence (Already in place pre-fix):** Relays delaying responses (e.g., 1 second delay) made it harder to successfully execute unbundling attacks by increasing the risk of missing the proposal slot if the proposer deviated.
## Detection
- Detection relies on monitoring proposer behavior for **equivocation attempts** (signing one commitment but proposing a structure that conflicts with the revealed block, although the slashing mechanism is generally meant to deter this).
- The key technical indicator would be relayer logs showing block material being returned to the proposer *without* a corresponding valid KZG commitment integrity check passing internally.
## References
- Vendor Advisories: Disclosure made responsibly to Gattaca (Helix developers).
- Relevant Links:
- Precursor Incident Post-Mortem: hxxps://collective.flashbots.net/t/post-mortem-april-3rd-2023-mev-boost-relay-incident-and-related-timing-issue/1540
- Helix Relay Repository: hxxps://github.com/gattaca-com/helix