Full Report
Ethereum is migrating to the newest fork Pectra. In order to make sure it's secure, the Ethereum foundation is hosting an attackathon on all Pectra-specific changes on Cantina with most Ethereum clients in scope, including the Ethereum Consensus client Lighthouse. The vulnerability would lead to a split of Lighthouse nodes from Ethereum, breaking consensus. Lighthouse had paralleled validator updates because changes made to one validator did not affect the other. In the Electra upgrade, consolidations were introduced that allow for exits straight to another validator. Naturally, these two things collide and it was noticed by the development team. To make this work with the parallelization strategy called single-pass epoch processing, the function process_effective_balance_updates was rerun on each validator index. Unfortunately, there are other functions with side effects run between these runs. This leads to different results when ran multiple times! Word of the day: hysteresis - a property lagging behind the changes in the effect causing it. There is a very detailed situation that is described that makes Lighthouse differ from the specification. By using the multiple updates, a node would have a different effective balance than they should. If Lighthouse was the only software used, this wouldn't be a huge deal. However, since it has to be perfectly aligned with the other clients, this is a problem. To fix the vulnerability, single-pass epoch processing only happens on validators unaffected by the consolidations. All nodes affected by consolidations are processed before updating their effective balances. They also mention the adding of specification and fault injection tests around this to try to find other variants of it. Overall a great find and an amazing write up about it.
Analysis Summary
# Vulnerability: Consensus Split due to Incorrect Effective Balance Processing in Electra
## CVE Details
- **CVE ID:** No known CVE (Pre-deployment discovery)
- **CVSS Score:** High (Severity reported as High by Sigma Prime)
- **CWE:** Not specified (Logic Flaw / State Inconsistency)
## Affected Systems
- **Products:** Lighthouse (Ethereum Consensus Client)
- **Versions:** This flaw was identified in the development/integration phase of the **Electra** upgrade.
- **Configurations:** Nodes running the Electra upgrade logic, specifically those utilizing "single-pass epoch processing" parallelization for validators involved in consolidations.
## Vulnerability Description
The Lighthouse client implements an optimization called “single-pass epoch processing” to update validator statuses in parallel. In the upcoming **Electra** upgrade, new features (EIP-7251) allow for "consolidations," where one validator can exit directly into another.
To maintain its parallelization strategy with these new changes, Lighthouse rerun the `process_effective_balance_updates` function on validator indices. However, effective balance updates in Ethereum are subject to **hysteresis** (a property where the output lags behind the input to prevent frequent flickering of values). Because this function was being run multiple times on the same validator due to consolidation logic, and because other functions with side effects occurred between these runs, the resulting effective balance would differ from the official Ethereum specification.
For example, a single net change might not trigger a balance update due to hysteresis thresholds, but splitting that change into two separate updates could trigger an incorrect downward adjustment.
## Exploitation
- **Status:** Not exploited (Discovered via the Ethereum Foundation "Attackathon" on Cantina before the Pectra/Electra fork mainnet launch).
- **Complexity:** High
- **Attack Vector:** Network (Triggered via specific sequences of partial withdrawals and consolidation requests).
## Impact
- **Confidentiality:** None
- **Integrity:** High (Leads to a different state than the official specification).
- **Availability:** High (If a Lighthouse node calculates a different state than other clients like Prysm or Teku, it will be rejected by the network, causing a consensus split/fork).
## Remediation
### Patches
- The development team has modified the `single-pass` epoch processing logic. Validators affected by consolidations are now excluded from the parallel single-pass loop and are instead processed sequentially before updating their effective balances to ensure the update occurs exactly once.
### Workarounds
- No manual workarounds are recommended; users must ensure they are running the latest version of Lighthouse that includes the Electra security fixes before the hard fork.
## Detection
- **Indicators of Compromise:** Consensus errors or "Invalid Block" alerts during the Electra fork transition.
- **Detection methods and tools:**
- **Differential Fuzzing:** The team is using fault injection and differential fuzzing to compare Lighthouse’s output against other consensus clients.
- **Spec Tests:** New specification tests have been upstreamed to the [ethereum/consensus-specs](https://github.com/ethereum/consensus-specs/pull/4239) repository.
## References
- **Vendor Advisory:** hxxps[://]github[.]com/sigp/lighthouse/security/advisories/GHSA-wm9c-xvqq-5c28
- **Consensus Specs PR:** hxxps[://]github[.]com/ethereum/consensus-specs/pull/4239
- **Formal Verification Project:** hxxps[://]github[.]com/sigp/verified-consensus