CryptoSlate
A flaw in Eclair, a Bitcoin Lightning implementation, could let a malicious peer crash an unpatched node without funding a channel or paying an on-chain fee. Nodes running v0.14.0 or earlier were affected. In a regtest proof of concept, researcher Erick Cestari exhausted a 4 GB Java heap in about 47 minutes 43 seconds after 217,623 channel database rows accumulated. The records remained on disk, causing the node to run out of memory again during startup.
Why it matters
Eclair limited how many pending channels a peer could open, but inconsistent checks of temporary and final channel identifiers let its counter undercount unfunded channels. An attacker could build up saved requests while imposing memory and database costs on the node. The attack still required computing resources and network traffic, but not the BTC normally committed to fund a channel.
The proof of concept shows a persistent availability failure on one vulnerable node, not live exploitation or a count of affected operators. Its measured crash time is a laboratory result, not a universal benchmark. The flaw was fixed in v0.14.1, released in July before the public disclosure.
Market impact
The finding concerns Lightning node availability, not a demonstrated loss of funds. A separate channel-opening race, also fixed in v0.14.1, left orphaned processes consuming resources; the tested node recovered from that bug on disconnect or restart. That recovery does not apply to the persistent database flood.
ACINQ recommends upgrading to v0.14.3 for separate security vulnerabilities. Operators with an already overloaded database face a distinct recovery task: Cestari identified increasing the heap or manually removing fake channel records as possible measures. Repeatedly restarting the node does not clear those records.
Frequently asked questions
-
Why can restarting an affected Eclair node fail to restore service?
The unfunded channel records remain in the database. Eclair can exhaust memory again when it reloads them during startup.
-
Does the persistent-crash attack require funding a Bitcoin Lightning channel?
No. A malicious peer could accumulate saved channel requests without broadcasting a funding transaction or paying an on-chain fee, though the attack still required computing resources and network traffic.
-
Which Eclair versions were affected, and which release fixed the flaw?
The persistent-crash flaw affected reachable nodes running v0.14.0 or earlier. It was fixed in v0.14.1, released in July before the public disclosure.
-
What did the Eclair proof of concept demonstrate?
In regtest, it exhausted a 4 GB Java heap after about 47 minutes 43 seconds, with 217,623 channel database rows accumulated. It did not establish live exploitation or a universal time to failure.
-
Why does ACINQ recommend v0.14.3 if v0.14.1 fixed these denial-of-service flaws?
Version v0.14.3 addresses separate security vulnerabilities. The v0.14.1 fix for the two denial-of-service findings is not a complete current security recommendation.
CoinDesk
Crypto News
TheBlock
Crypto Rank News
WuBlockchain
Glassnode