Eclipse Attack

Overview

An eclipse attack surrounds a target node with attacker-controlled peers, preventing or delaying connections to honest participants. The isolated node receives a distorted view of transactions, blocks, chain tips, fees, or network activity while believing it remains normally connected.

Attackers may exploit predictable peer selection, address-table poisoning, excessive inbound connections, network routing weaknesses, or repeated restarts. Isolation can support double-spend attempts, selfish mining, transaction censorship, delayed settlement, or deception of services that rely on one node.

Defenses include diversified peer selection, protected seed sources, limits by network range, persistent trusted peers, authenticated connections where available, and monitoring for abnormal topology or chain divergence. Critical payment systems should compare independent nodes and external network observations.

For Eclipse Attack, an indicator supplies evidence, a control changes exposure, a policy states expectations, and an incident records an event; using those labels interchangeably obscures decisions.

Eclipse Attack is an attack or weakness pattern that isolates a blockchain node from honest peers so an attacker can control the network information that node receives. A node can follow valid protocol rules yet remain dangerously misinformed when attackers control all of its network connections.

Assessment of Eclipse Attack should trace an attack or weakness pattern that isolates a blockchain node from honest peers so an attacker can control the network information that node receives from prerequisite and entry point through observable impact on the affected service. A theoretical weakness or scanner result involving attack should not be reported as exploitation without corroborating logs, transactions, or configuration evidence. Prevention, detection, containment, and recovery for the Eclipse attack path should be tested against the architecture associated with attack.