Study Shows Feasibility of Eclipse Attack on Ethereum 2.0 Nodes

Global: Study Shows Feasibility of Eclipse Attack on Ethereum 2.0 Nodes

Researchers have demonstrated the first end‑to‑end eclipse attack against Ethereum 2.0 execution‑layer nodes, showing that a malicious actor can fully isolate a node after it restarts. The work, posted on arXiv, details how the attackers manipulate peer‑discovery mechanisms, poison DNS‑based peer lists, and hijack idle connection slots to achieve isolation on both the Sepolia testnet and the Ethereum mainnet.

Background

Eclipse attacks, which monopolize a node’s peer‑to‑peer connections, have been extensively examined in Bitcoin and Monero. However, the post‑Merge Ethereum ecosystem has received comparatively little attention, leaving a gap in understanding the practical risks to its network participants.

Attack Methodology

The authors outline a three‑stage strategy. First, they poison the target node’s discovery table by sending unsolicited messages that overwrite legitimate entries. Second, they infiltrate Ethereum’s DNS‑based peer list by identifying the official DNS crawler and inserting malicious IP addresses. Finally, they hijack idle incoming connection slots across the network, preventing benign peers from establishing connections.

DNS List Poisoning

According to the study, the DNS poisoning component required only 28 IP addresses over a 100‑day period, marking the first instance of DNS list manipulation in a cryptocurrency context. This low resource requirement underscores the attack’s practicality.

Slot Hijacking Effectiveness

Experimental results indicate that hijacking idle slots raises the success rate of outgoing redirection from 45% to 95%, dramatically increasing the likelihood of achieving a complete eclipse.

Network Measurements

Broad measurements on the Ethereum mainnet revealed that more than 80% of public nodes lack sufficient idle capacity to resist slot occupation, highlighting a systemic vulnerability in current node configurations.

Proposed Countermeasures

The authors recommend several mitigations, including stricter validation of DNS‑provided peer lists, dynamic adjustment of idle slot thresholds, and enhanced peer‑management logic to detect anomalous connection patterns.

Responsible Disclosure

All findings were responsibly disclosed to Ethereum’s security team prior to public release, allowing developers to begin addressing the identified weaknesses.

Implications

By exposing a viable eclipse attack vector, the research emphasizes the need for ongoing security assessments of Ethereum’s peer‑discovery and connection‑management subsystems, especially as the network continues to evolve.

This report is based on information from arXiv, licensed under Academic Preprint / Open Access. Based on the abstract of the research paper. Full text available via ArXiv.