Eclair operators reviewing the latest Lightning security disclosures face an easy trap: several notices describe denial of service, but they do not all concern the same bug or the same fixed version. Erick Cestari's October 1 post describes two channel-opening flaws affecting v0.14.0 and earlier, with fixes in v0.14.1. Meanwhile, ACINQ's current release page recommends v0.14.3 for additional security hardening. October disclosure and current release.
That distinction matters when an old advisory circulates again. Its minimum fixed version answers a narrow question about the identified vulnerability. It does not establish that the same version contains every subsequently released security fix.
One crash can survive a restart
Cestari's September 30 research describes an unfunded-channel flood. In the affected implementation, inconsistent channel-identity tracking allowed pending channels to escape the intended limit. The receiving node incurred memory and database costs even though the attacker never broadcast the channel's funding transaction. Researcher's account.
The persistence of those records made the failure especially troublesome. Reloading them on startup could exhaust memory again, leaving the node in a crash loop. Cestari demonstrated the issue against v0.14.0 in Bitcoin's local regtest environment. His reported timing is a laboratory result, not a prediction for every deployment. Test setting and restart behavior.
The operational lesson is that restarting a service cannot be assumed to remove the state that caused its failure. An operator encountering repeated crashes needs version-specific diagnosis and a recovery plan that protects legitimate channel records. This article does not provide database-cleanup instructions.
A separate race had a different recovery outcome
Matt Morehouse's LNF-2026-0003 advisory concerns a race during channel opening. A check and a later update could become inconsistent, leaving channel-processing objects untracked while they continued consuming resources. Repeated activity could exhaust memory or leave the node spending its time on memory cleanup. lnfuzz advisory.
In Morehouse's test, the node recovered after a disconnect or restart, with nothing lost. He assessed the risk to funds as likely low for that tested behavior. Those qualifications belong to this advisory; they should not be copied onto the persistent database-flood finding. The advisory records a July 17 fix and a July 29 release in v0.14.1, ahead of public disclosure on September 30. Impact and timeline.
For a reader, this is a useful way to evaluate a security headline: identify the affected component, the failure mode, whether problematic state survives a restart, and the fixed release. A shared label such as denial of service can hide meaningful differences.
Earlier disclosures cover another version boundary
Morehouse's September 24 notice addresses two other Eclair issues: costly feature-bit parsing and unbounded decompression of older channel-query messages. Both affected v0.13.1 and earlier and were fixed in v0.14.0. These are separate from the channel-opening problems fixed in v0.14.1. September 24 disclosure.
This layered timeline explains why an operator can truthfully say a particular bug is patched while still needing a newer release. It also limits what the disclosures establish. Demonstrations of vulnerable software do not supply a count of currently exposed nodes or, by themselves, evidence of exploitation against live services.
Read the upgrade requirements alongside the advisory
As checked on October 12, ACINQ marks v0.14.3 as its latest Eclair release. The September 14 release announcement strongly recommends upgrading because malicious nodes can exploit some of the issues addressed. Maintainer release announcement.
Preparation should include the intervening release notes. Version 0.14.1 specifies Bitcoin Core 31.x and warns operators with custom BOLT12 offer-handler plugins about a removed fee-discount behavior. Those are concrete integration requirements, beyond replacing the Eclair executable. Version 0.14.1 requirements.
Version 0.14.3 also introduces a cap on estimated funding and splice transaction fee rates. Its notes explain the tradeoff: a cap can prevent excessive fees, but transactions may remain unconfirmed when congestion requires more. Operators should review that setting against their deployment rather than treating a software update as configuration-free. Version 0.14.3 configuration notes.
For mobile-wallet customers, responsibility may sit with the service operator. In an October 6 reply, Morehouse said users of wallets relying on ACINQ's Eclair nodes, including Phoenix, should be unaffected by the disclosed channel-opening flaws because ACINQ had patched its nodes months earlier. That statement is specific to these vulnerabilities. Researcher's clarification.
The practical next step is to establish who runs the node, record its actual version, and compare it with current maintainer guidance. Keep the incident diagnosis and the upgrade decision tied to the correct advisory.