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

A newly disclosed unfunded-channel flaw could leave Eclair, a Bitcoin Lightning implementation, crashing repeatedly without an attacker spending BTC on-chain. The flaw affected reachable nodes running v0.14.0 and earlier, with saved channel records making a restart insufficient to restore service.

Researcher Erick Cestari published the persistent-crash finding Sept. 30 and explained it alongside a separate denial-of-service bug in an Oct. 1 developer post. Both were fixed in v0.14.1, released in July, before the public disclosures. ACINQ now recommends the later v0.14.3 security release for separate vulnerabilities.

Why restarting could fail

Eclair limited the number of pending channels a peer could open, but inconsistent checks of temporary and final channel identifiers let its counter undercount unfunded channels. A malicious peer could accumulate saved requests without broadcasting the funding transaction or paying an on-chain fee.

That distinction matters: the BTC normally needed to fund a channel did not have to be committed for the vulnerable node to incur memory and database costs. The attack still required computing resources and network traffic.

In Cestari’s proof of concept, Eclair v0.14.0 ran in regtest, Bitcoin’s local testing environment. He reported that the node exhausted a 4 GB Java virtual machine heap after about 47 minutes 43 seconds, with 217,623 rows accumulated in the channel database. That is one laboratory benchmark, not a universal attack duration.

The initial crash left those records on disk. During startup, Eclair reloaded the channels and exhausted memory again. Cestari described increasing the heap or manually removing fake channel records as recovery measures. Repeated restarts left the underlying load in place.

The demonstration concerns one vulnerable node’s availability. It does not establish live exploitation or the number of unpatched nodes.

ACINQ merged PR #3324 July 17. The patch strengthened duplicate-channel checks, and v0.14.1 shipped July 29. According to Erick Cestari / Delving Bitcoin, v0.14.0 and earlier are affected, while v0.14.1 or later addresses these two denial-of-service findings.

The second bug, disclosed by Matt Morehouse / lnfuzz as LNF-2026-0003, was a channel-opening race that left orphaned channel processes consuming memory or CPU. His advisory says the tested node recovered on disconnect or restart without loss. That recovery result belongs to the race bug, rather than the persistent database flood.

These findings also differ from the fund-loss vulnerabilities CryptoSlate covered Sept. 21, which were patched in v0.14.3. The July minimum fix should therefore not be read as a complete current security recommendation.

ACINQ recommends upgrading to v0.14.3, released Sept. 14, because malicious nodes could exploit some of the issues it fixed. Preventing new unfunded-channel floods and recovering an already overloaded database are separate operator concerns.