Bitcoin Lightning Network developer ACINQ released Eclair 0.14.6 on October 27, addressing a risk in which a malicious node could exploit unconfirmed channel-funding transactions. The update requires confirmed funding inputs for channel splicing by default and revises settlement and fund-recovery procedures when a channel closes. ACINQ urged node operators to upgrade, though it is not known whether the vulnerabilities have been exploited in practice.
How unconfirmed funds could put pending payments at risk
The Lightning Network processes bitcoin transfers through payment channels, avoiding the need to record each payment on the Bitcoin blockchain. Operators can also add or withdraw liquidity from an existing channel through “splicing,” a process that relies on on-chain transactions.
The risk arises when a splice accepts funding inputs supplied by a counterparty before those inputs have been confirmed by the Bitcoin network. A malicious node could double-spend the relevant transaction after signing the splice. If that invalidates the original funding arrangement, settlement of the channel could also be affected.
If the channel is then closed on-chain, pending payments secured by hash time-locked contracts (HTLCs) may be exposed because their settlement depends on the invalidated funding transaction. ACINQ described this as a potential security issue; it did not report a confirmed theft of funds.
Confirmed inputs required for splicing by default
Eclair 0.14.6 adds a security setting that requires a counterparty’s funding inputs for a splice to be confirmed before they can be used. It also prevents operators from building further splice transactions on top of funding changes that remain unconfirmed, limiting the accumulation of unsettled funding states.
ACINQ said this requirement is separate from Eclair’s existing dual-funding protections, which now apply specifically to channel creation. Splicing is covered by the new confirmation check. For untrusted counterparties, ACINQ also advised operators against using the optional zero-fee commitment feature during a splice. The feature was already disabled by default.
Forced closures fall back to confirmed funding states
The release also changes how Eclair handles a channel that must close while its funding transaction is still unconfirmed. Under the revised settlement logic, Eclair selects a commitment transaction that its Bitcoin Core backend recognizes as funded. Where necessary, it falls back to the latest confirmed funding state rather than settling against a funding transaction that has disappeared from the local mempool.
Another fix addresses transactions that miners may confirm even after Eclair no longer considers them the preferred settlement path. Under the previous logic, such transactions could be misclassified as belonging to the counterparty, leaving recoverable funds and pending-payment outputs unclaimed. The new version identifies these transactions and attempts to recover the associated outputs.
Existing channels can stay open during the upgrade
ACINQ said nodes still running older Eclair versions should install the patch and keep the confirmed-input protection enabled by default. Operators must stop the software, install the new version and restart the node. Existing payment channels do not need to be closed during the upgrade.
Security researcher Erick Cestari responsibly disclosed the issues addressed in the release. ACINQ warned that malicious nodes could exploit some of them, but has not disclosed how many nodes may have been affected or whether any attacks have occurred.