A new Monero eclipse attack isolates unreachable nodes running behind a firewall or Network Address Translation (NAT), a group long considered safer than nodes with public IP addresses. Research accepted at the ACM Conference on Computer and Communications Security (CCS) 2026 shows an attacker can take over all 12 outgoing connections of a NAT-protected node without opening a single inbound connection to it.
Researchers from Beijing University of Posts and Telecommunications, Zhejiang University, Hong Kong Polytechnic University and CSIRO posted an updated preprint on October 25, 2026.
Monero hides amounts with RingCT and recipients with stealth addresses, while the network layer depends on honest peer connections. A Monero eclipse attack cuts a victim off from the honest network and gives the adversary control over the blocks and transactions the victim receives, enabling deanonymization, network partitioning and selfish mining advantages.
Earlier eclipse research on Monero in 2025, on Bitcoin in 2015 and on Ethereum in 2026 assumed the attacker could open inbound connections to the target, which excluded nodes behind NAT. Mainnet measurements place 80.64% of observed Monero nodes in the unreachable category, a majority of the network.
How the Monero eclipse attack abuses peerlist mechanics
Every node keeps a whitelist of up to 1,000 verified peers and a graylist of up to 5,000 unverified candidates. Because a node behind NAT accepts no inbound connections, it learns about peers from its 12 outgoing peers alone. Each handshake or timed sync response carries up to 250 peer records, which the receiving node writes into the graylist, and the graylist evicts its oldest entries at capacity.
The protocol rotates outgoing connections on its own, with no failure or restart required. The function update_sync_search() releases one outgoing slot about every 101 seconds and draws the replacement from the graylist first. A Monero eclipse attack combines list poisoning with the rotation cycle: malicious peers fill the lists, and the cycle swaps honest peers for attacker-controlled ones.
Nyx and Moros: two variants of the Monero eclipse attack
Nyx applies the Monero eclipse attack to existing unreachable nodes in three phases, beginning with the poisoning of reachable nodes’ whitelists using 1,000 IP addresses from distinct /24 subnets. After the poisoned records reach the target’s graylist through timed sync responses, the rotation function replaces benign outgoing peers with malicious ones.
Port diversity lets the peerlist poisoning reach the target’s graylist at scale, because the graylist deduplicates records by IP and port pair and attacker IPs announcing one port would place at most 1,000 entries. Nyx assigns a distinct port to each reachable node, and the target receives up to 3,000 distinct records per timed sync round.
Moros applies the Monero eclipse attack to newborn nodes through the six hardcoded seed nodes, which supply the peer candidates of every node joining the network. A new node starts with empty lists, so a single seed handshake returning up to 250 records defines its candidate set. Poisoned seed whitelists hand the attacker the candidate set ahead of any contact with an honest peer, an outcome called eclipse at birth.
Test results: 27 minutes for Nyx, 8 seconds for Moros
Researchers evaluated the Nyx variant of the Monero eclipse attack in an emulated network of 1,200 Monero nodes running version 0.18.4.3, with latency, jitter and packet loss calibrated to mainnet measurements; ethical limits kept the attack off the live network. At minute five, 89.6% of reachable nodes held whitelists at least 95% malicious, and the share reached 99.5% at minute ten.
The target’s graylist held 717 benign entries at launch, and the benign count dropped to zero once the graylist reached its 5,000-entry capacity at minute four. The target lost all 12 outgoing slots to the attacker at about minute 27, in a connection takeover spanning 17 rotation rounds, with 16 picking malicious peers. The eclipse held through an 18.2-hour monitoring window, and from minute 85 of the experiment onward the target stayed at 12 of 12 attacker-controlled connections.
Moros demonstrated the Monero eclipse attack against a controlled node on the Monero mainnet, started with –hide-my-port to simulate unreachability. Poisoning of the six seed nodes with 1,000 IP addresses stabilized at an average of 934 malicious whitelist entries (93.4% occupation).
The new node received 233 malicious records out of 250 and lost all 12 outgoing connections to the attacker within 8 seconds. Since the 1,000 IP addresses came from a narrow range of subnets, the test disabled the target’s /24 subnet-diversity filter.
Why unreachable nodes cannot recover from an eclipse
An unreachable node has no inbound path, so after a Monero eclipse attack no honest peer can open a connection to correct its view. With all outgoing peers under attacker control, the node relies on them for peer discovery and every rotation decision, which makes the eclipse self-reinforcing.
Local monitoring offers limited protection because the node observes changes following normal protocol behavior, and a newborn node has no earlier state for comparison.
The attack needs modest resources: 1,000 IP addresses across distinct subnets, available from cloud providers and proxy pools, suffice for a Monero eclipse attack against one target, and Monero’s /24 subnet filter forces the attacker to span at least 12 subnets, a threshold 1,000 subnets exceeds by a wide margin.
ProbeLab’s February 2026 crawl flagged 13,420 of 16,454 reachable nodes (81.6%) for inconsistent peer identifiers, all resolving to infrastructure of one hosting provider. Unreachable nodes draw outgoing peers from the reachable pool, which ties their exposure to the quality of reachable nodes. A campaign of about 130 malicious nodes attempted Sybil and eclipse tactics against Monero after the v0.17 upgrade in October 2020.
Monero patches limit peerlist exchange, but Sybil exposure remains
Monero developers proposed a fix restricting peerlist exchange and graylist insertion after the research team reported the vulnerabilities through HackerOne under identifier #3702913. Existing defenses did not stop the Monero eclipse attack: the anchor list covers restarts, the v0.18.3.2 patch retains connections during double-spend conflicts and leaves automatic rotation untouched, and the v0.18.4.3 /24 filter raises attacker cost by a constant factor.
The proposal caps each connection at 250 returned records per 10-minute window and 250 received records per 5-minute window, ignores extra ports from an IP already in the graylist, and rejects new records from an IPv4 /16 subnet holding 64 entries. Legitimate nodes pay in slower peer discovery, and a single record per shared public IP passes the insertion check.
The limits close specific poisoning paths and leave the Sybil precondition in place, since an adversary with enough identities still shapes the peer information an unreachable node receives. Long-term protection needs peer information independent of current outgoing peers, through identity binding to scarce resources or independent channels verifying the node’s network view.
Outbound-only nodes in other networks, with neighbor-based peer discovery and locally bounded peerlists, may face the same dynamics, extending the Monero eclipse attack pattern beyond one cryptocurrency.
Isai Alexei is a journalist and financial analyst covering cryptocurrency markets and traditional securities for Blockchaindose. He has spent ten years analyzing digital assets, trading activity, and market structure.
