Eclair discloses two channel-opening bugs that could crash a Lightning node

Serguey Asael Shinder02 October 2026, 07:432 min read

Two more denial-of-service vulnerabilities in Eclair, ACINQ's Lightning Network implementation, were disclosed on Delving Bitcoin on 1 October. Both sat in the channel-opening flow and are fixed in Eclair v0.14.1, released on 29 July; operators are advised to run v0.14.1 or later. This follows a disclosure of two other Eclair bugs, fixed in v0.14.0, on 24 September.

The first was a race condition. Eclair rejects a duplicate temporary_channel_id by checking the peer's channel map, but there is a delay between that check and the moment the new channel is added to the map. An attacker who pipelines several identical open_channel messages can get two of them past the check, so Eclair starts two channel actors for one id. The second overwrites the first in the map, leaving an orphaned actor holding about 25 KB until the peer disconnects. Repeated, the disclosure says, this leaks about 1 MB per second and ends in an out-of-memory crash or a garbage-collection spiral that takes the node off the network. Matt Morehouse found it with his fuzzer, smite, which flagged that Eclair sometimes accepted two open_channel messages with the same id.

The second bypassed the limiter meant to stop fake-channel attacks, which caps the number of unconfirmed channels in flight. By reusing each channel's final id as the temporary id of the next open_channel, an attacker made the limiter track one id twice and then remove both entries at once, so its count never rose above two while real pending channels grew without bound. Each channel stores a copy of the peer's init features; inflated to about 65 KB, they made every channel cost that much memory. According to the disclosure, a single connection, at no on-chain cost, ran a node with a 4 GB heap out of memory in about 48 minutes. Because the channels are persisted, the node crashed again on every restart until the heap was raised or the rows deleted by hand. The author of that report says it was found with an LLM-based harness that maps a codebase's entry points and the invariants each should hold, checked against the BOLT specifications, and that they confirmed it and built the proof of concept themselves.

Why it matters

The persisted-channel bug is the harder one: a node that crashes on every restart needs an operator to intervene by hand. And as with last week's disclosure, the finding tools are now half fuzzer and half language model, which suggests more such reports are coming across Lightning implementations.