Unpatched Eclair Bitcoin Lightning nodes could crash again every time they restart

A newly revealed vulnerability involving unfunded channels could cause Eclair—a Bitcoin Lightning network implementation—to experience repeated crashes without requiring an attacker to spend bitcoin on-chain. This issue impacts reachable nodes operating on version 0.14.0 and prior iterations, with stored channel records preventing a simple reboot from successfully restoring operations.

On Sept. 30, researcher Erick Cestari released findings regarding this persistent-crash issue, detailing it alongside a separate denial-of-service vulnerability in an Oct. 1 developer update. Both security problems were resolved prior to public disclosure via v0.14.1, which launched in July. ACINQ currently advises upgrading to the subsequent v0.14.3 security release to address separate vulnerabilities.

Why restarting could fail

Eclair previously restricted the volume of pending channels that any peer was allowed to open. However, inconsistent evaluations of temporary versus final channel identifiers caused its tracking mechanism to miscount unfunded channels. Consequently, a malicious peer could amass stored requests without needing to broadcast a funding transaction or pay on-chain fees.

This distinction is significant because the bitcoin typically required to capitalize a channel did not need to be committed for the targeted node to rack up database and memory expenses. Nonetheless, the attack still demanded network traffic and computing power.

During Cestari’s proof-of-concept testing, Eclair v0.14.0 was executed inside regtest, which serves as Bitcoin’s local testing framework. He documented that the node depleted a 4 GB Java virtual machine heap in roughly 47 minutes and 43 seconds, generating 217,623 entries inside the channel database. This serves as a single laboratory benchmark rather than a universal timeline for an attack.

The initial crash preserved those records on the disk storage. Upon rebooting, Eclair reloaded the channel entries and once again ran out of memory. As recovery solutions, Cestari noted options such as expanding the heap size or manually purging fraudulent channel records. Performing standard reboots without these interventions left the underlying workload intact.

This demonstration focuses strictly on the availability of a single vulnerable node. It does not prove that live exploitation has occurred or specify the total quantity of unpatched nodes in existence.

ACINQ merged pull request #3324 on July 17. The patch enhanced validations for duplicate channels, and v0.14.1 was subsequently rolled out on July 29. As outlined by Erick Cestari via Delving Bitcoin, versions 0.14.0 and earlier remain vulnerable, whereas v0.14.1 and newer iterations resolve both denial-of-service discoveries.

The second vulnerability, highlighted by Matt Morehouse alongside lnfuzz under the designation LNF-2026-0003, involved a channel-establishment race condition that left orphaned channel processes consuming CPU or memory resources. According to his security advisory, the tested node managed to recover following a disconnection or reboot without experiencing any asset loss. That recovery behavior applies specifically to the race condition bug rather than the persistent database flood.

These findings also contrast with the fund-loss vulnerabilities reported by CryptoSlate on Sept. 21, which received patches in v0.14.3. Therefore, the minimum fix issued in July should not be interpreted as an all-inclusive, up-to-date security recommendation.

ACINQ advises upgrading to v0.14.3, which launched on Sept. 14, given that malicious nodes could potentially exploit certain issues resolved within it. Stopping future unfunded-channel floods and restoring a database that is already overburdened represent two distinct challenges for node operators.

?Frequently Asked Questions

01What causes the Eclair node to crash repeatedly?

Inconsistent validation checks for temporary and final channel identifiers led Eclair to undercount unfunded channels. Malicious peers could accumulate saved channel requests without paying on-chain fees, exhausting the node’s memory and leaving residual data that causes repeated crashes upon restart.

02Which versions of Eclair are vulnerable?

Nodes running version 0.14.0 and earlier are affected by the unfunded-channel flaw and related denial-of-service bugs.

03What is the recommended fix for operators?

ACINQ recommends upgrading to version v0.14.3 (released Sept. 14) or later to address the security vulnerabilities. Operators dealing with an already overloaded database may also need to manually clear fake channel entries or expand their Java virtual machine heap size for recovery.