A newly revealed vulnerability involving unfunded channels could cause Eclair—a Bitcoin Lightning network implementation—to crash continuously without requiring an attacker to spend BTC on-chain. Reachable nodes running version 0.14.0 and earlier are impacted, and because channel records are saved locally, simply restarting the software is not enough to restore normal service.
Researcher Erick Cestari made the persistent-crash discovery public on Sept. 30, detailing it alongside a separate denial-of-service flaw in an Oct. 1 developer post. Both issues were patched in version 0.14.1, which was released in July ahead of the public disclosures. ACINQ currently advises upgrading to the v0.14.3 security release to protect against separate vulnerabilities.
Why restarting could fail
While Eclair enforced a limit on how many pending channels a peer could initiate, inconsistent validation between temporary and final channel identifiers caused its counter to miscalculate unfunded channels. Consequently, a malicious peer could amass stored requests without ever broadcasting a funding transaction or paying on-chain fees.
This distinction is crucial: the vulnerable node incurred database and memory expenses even though the BTC normally required for channel funding did not need to be committed. The attack still demanded network traffic and computing power, however.
During Cestari’s proof-of-concept testing, Eclair v0.14.0 was executed within regtest, Bitcoin’s local testing environment. He noted that the node depleted a 4 GB Java virtual machine heap in roughly 47 minutes and 43 seconds, generating 217,623 entries in the channel database. This serves as a single laboratory benchmark rather than a universal timeline for attacks.
Because the initial crash preserved these records on disk, Eclair reloaded the channels upon startup and immediately ran out of memory again. To recover, Cestari suggested either increasing the memory heap size or manually deleting the fraudulent channel entries, as performing ordinary restarts left the problematic data intact.
This demonstration focuses strictly on the availability of a single vulnerable node. It does not prove that live exploitation has occurred, nor does it specify how many unpatched nodes exist in the wild.
ACINQ integrated pull request #3324 on July 17 to tighten duplicate-channel validation, and version 0.14.1 followed on July 29. According to findings shared by Erick Cestari on Delving Bitcoin, versions 0.14.0 and prior are vulnerable, while version 0.14.1 and later resolve these two denial-of-service issues.
A second bug, identified as LNF-2026-0003 and disclosed by Matt Morehouse of lnfuzz, involved a channel-opening race condition that left orphaned channel processes hogging CPU or memory resources. His advisory noted that the tested node successfully recovered following a disconnect or restart without any data loss—a recovery outcome specific to the race condition rather than the persistent database flooding.
Furthermore, these discoveries are distinct from the fund-loss vulnerabilities reported by CryptoSlate on Sept. 21, which were subsequently fixed in version 0.14.3. Consequently, the minimum fixes deployed in July should not be viewed as a complete, up-to-date security recommendation.
ACINQ advises operators to update to version 0.14.3, which launched on Sept. 14, given that malicious actors could potentially exploit certain flaws addressed in that release. Note that blocking new unfunded-channel floods and restoring an already overwhelmed database represent two separate challenges for node operators.