Eclair denial-of-service bugs: what Lightning operators should check

By Ledgers Academy Editorial Desk
Published and reviewed: 20 October 2026. Educational analysis.

The Eclair denial-of-service disclosures show how a Lightning node can lose availability before a channel has received any bitcoin. Two flaws in channel-opening bookkeeping allowed a malicious peer to consume resources that the node believed it had limited. The useful lesson reaches beyond this implementation: a payment system must account correctly for unfinished work, as well as validate completed payments.

These are patched vulnerabilities with a documented disclosure history. Matt Morehouse and Erick Cestari published technical accounts dated 30 September 2026; Cestari summarised both on 1 October. Their reports identify Eclair v0.14.0 and earlier as affected and v0.14.1 as fixed. This article examines those two availability bugs, without treating every recent Lightning software change as one incident.

There is a current reason to revisit the distinction. ACINQ's 15 October 2026 release, v0.14.4, adds further security hardening, and the maintainers strongly recommend upgrading. Version 0.14.1 is the historical fix boundary for the two bugs discussed here; operators planning maintenance today should consult the latest release and its compatibility guidance.

Eclair denial-of-service: what failed before funding

Eclair is ACINQ's Lightning node implementation. Lightning channels let peers update a payment relationship offchain, backed by transactions enforceable on Bitcoin. Readers new to the model can start with our Lightning Network explainer.

The BOLT 2 channel-management specification describes an opening conversation before a channel becomes usable. In the single-funded flow relevant here, a temporary identifier links the initial messages. A later identifier is derived from the proposed funding transaction's output. The receiving node must retain enough state to continue the conversation while funding remains unconfirmed.

That creates a resource-management problem. An opening request is not proof that the sender will complete the transaction. A node therefore needs limits on unfinished channels. Those limits must follow the actual objects occupying memory and storage, even as identifiers change. In the Editorial Desk's assessment, this is the central boundary illustrated by the disclosures: accepting a valid-looking conversation also commits the receiver to work.

Two ways for the count to diverge from reality

Morehouse's advisory, LNF-2026-0003, describes a timing flaw. Eclair checked whether an opening identifier was already present, then performed other processing before recording it. Closely timed requests could both pass that check. Two internal channel objects were created, but only one remained reachable through the channel map; the other continued consuming memory.

The advisory reports roughly 25 KB retained per orphaned object and an observed leak around 1 MB per second during testing. Those measurements describe the research setup, not a universal crash speed. Morehouse assigns this issue a low severity rating. Its reported outcomes include memory exhaustion or CPU saturation from repeated garbage collection. The retained objects were released when the attacking peer disconnected.

Cestari's separate account concerns identifier tracking across temporary and final channel states. An identifier collision could make the pending-channel limiter undercount the objects still alive. Channels accumulated while its bookkeeping suggested that capacity remained available.

That second failure also reached persistent storage. In Cestari's reported local test, enlarged peer-feature data copied into each channel helped exhaust a 4 GB Java heap in about 48 minutes. The attack required no onchain transaction payment. Restarting reloaded the stored channels, reproducing memory pressure and causing a crash loop. These are researcher-reported test results; they do not establish the number of production nodes affected.

Availability matters, but scope matters too

Neither account demonstrates a private-key extraction or a break in Bitcoin's signature scheme. The direct result described is loss of node availability. A reader should not turn a successful denial-of-service test into an unsupported claim that all Lightning balances were stolen or that the whole network stopped.

Editorial Desk analysis: availability still has economic consequences. A merchant may be unable to complete payments through its chosen service. A routing operator may lose opportunities to forward transactions and spend time recovering infrastructure. For a service that depends on timely responses, recovery procedures belong beside key protection in its security plan. An outage and a theft are different events, but both deserve operational attention.

There is also a useful counterargument to sweeping conclusions: Lightning consists of multiple implementations and independently operated nodes. Evidence about a particular Eclair version cannot establish an identical flaw elsewhere. Nor does the existence of alternative routes guarantee that a particular wallet or merchant can immediately use them. Dependency choices determine how a local failure reaches an end user.

What the fix and release history establish

ACINQ merged pull request #3324 on 17 July 2026. Its changes reject conflicts with final channel identifiers earlier and recheck duplicates after the asynchronous rate-limiting step. That second check addresses the gap between inspecting state and acting on it. The implementation record corroborates the researchers' explanation of the faulty boundary.

The v0.14.1 release was published on 29 July 2026, before the September disclosures. ACINQ's upgrade instructions say existing channels do not need to be closed for that release: stop the node, upgrade and restart. The detailed release notes also require Bitcoin Core 31.x and flag a change affecting custom offer-handler plugins. Operators need the compatibility notes, not just a version number copied from a headline.

Who should check what

For operators, the first question is the version actually running, including containers and standby instances. The disclosures recommend v0.14.1 or later for these issues. Installation files on disk do not establish that a restarted service is using them. A practical review should record the running version, dependency versions and the outcome of ordinary payment checks after maintenance.

For wallet users, establish who operates the relevant node. In a 6 October reply to the disclosure, Morehouse said users of mobile wallets using ACINQ's Eclair nodes as a Lightning service provider, such as Phoenix, should be unaffected because ACINQ had patched its nodes months earlier. That is a specific researcher statement about that deployment, not a blanket assurance about every wallet or provider.

Editorial Desk analysis: monitoring should compare resource consumption with what the application claims to be doing. Growing memory or database size alongside a low pending-channel count deserves investigation. Recovery rehearsals should include failures that survive restarts. The researchers' description of manual database intervention is not a general recovery recipe; channel records should not be deleted casually. Preserve evidence and seek implementation-specific guidance if a node is already failing.

What remains unknown

The reviewed disclosures and release records do not provide a network-wide count of vulnerable installations, a verified total of production outages, or evidence sufficient to attribute any particular user's failed payment to these bugs. We have not independently reproduced the researchers' tests. The patch evidence supports a concrete version check; it does not support an industry-wide loss estimate.

For readers evaluating infrastructure, this case adds a precise question to our protocol evaluation framework: when a peer abandons work halfway through, who pays for the state left behind, and how is it removed? Correct signatures are essential. So are honest counters, bounded resource use and a tested path back to service.