Two denial-of-service vulnerabilities in Eclair, the Bitcoin Lightning implementation maintained by ACINQ, exposed node operators to repeated crash loops because a restart could not clear poisoned channel records from disk, according to disclosures published Sept. 30 and Oct. 1 by security researcher Erick Cestari.

The persistent-crash flaw affected Eclair v0.14.0 and earlier on reachable nodes. A malicious peer could trigger memory exhaustion and leave saved channel records behind, so every subsequent startup reloaded the same payload and crashed the node again. ACINQ shipped the fix in v0.14.1 on July 29, roughly two months before the public disclosure, having merged the patch as PR #3324 on July 17.

The root cause sits in how Eclair counted pending channels. The implementation capped the number of channels a peer could open, but inconsistent checks of temporary and final channel identifiers let its counter undercount unfunded channels. An attacker could accumulate saved channel requests without ever broadcasting a funding transaction or paying an on-chain fee — the BTC normally required to open a Lightning channel never had to be committed. The attack still consumed the attacker's own computing resources and network traffic.

Cestari's proof of concept ran Eclair v0.14.0 in regtest, Bitcoin's local testing environment. The node exhausted a 4 GB Java virtual machine heap after roughly 47 minutes and 43 seconds, with 217,623 rows accumulated in the channel database. That figure is one laboratory benchmark, not a universal attack duration. The demonstration concerns a single node's availability; it does not establish live exploitation or quantify how many reachable nodes remain unpatched.

The operational consequences distinguish this bug from ordinary denial-of-service findings. Because the initial crash left the fake channel records on disk, a simple restart restored nothing. During startup, Eclair reloaded the channels and exhausted memory again. Cestari described two recovery measures for already-compromised nodes: increasing the JVM heap or manually removing the fake channel records from the database. Repeated restarts left the underlying load in place, meaning operators of vulnerable versions faced an indefinite outage until they intervened directly or upgraded.

Cestari disclosed a second, separate denial-of-service bug in an Oct. 1 developer post on the Delving Bitcoin forum. That flaw, reported by Matt Morehouse of lnfuzz as advisory LNF-2026-0003, was a channel-opening race condition that left orphaned channel processes consuming memory or CPU. Morehouse's advisory says the tested node recovered on disconnect or restart without loss. That clean-recovery result belongs to the race bug alone, not to the persistent database flood, which survives restarts by design of its persistence mechanism.

Both findings differ materially from the fund-loss vulnerabilities patched in v0.14.3. Those earlier-disclosed flaws threatened direct theft of channel funds, not merely availability. This distinction carries an operational warning for node operators: the July v0.14.1 release fixes the two denial-of-service issues but does not constitute a complete current security posture.

ACINQ recommends upgrading to v0.14.3, released Sept. 14, because malicious nodes could exploit some of the issues fixed in that release. The company's guidance implies operators face two separate tasks: deploying v0.14.3 to prevent new unfunded-channel floods and other exploits, and — for nodes already carrying an overloaded database from a pre-patch attack — clearing the accumulated records before the deployment will restore normal service.

Operators running Eclair v0.14.1 or v0.14.2 remain exposed to the vulnerabilities addressed in the September release, and nodes still on v0.14.0 or earlier remain exposed to both disclosure sets. With the technical details now public since the start of October, any unpatched reachable node is a viable target for an attack whose cost to the attacker is limited to compute and bandwidth rather than on-chain fees.