ACINQ released Eclair 0.14.5 on October 20, 2026, urging operators of its Bitcoin Lightning software to upgrade because malicious nodes could exploit security weaknesses. The fixes address payment-routing and channel-funding checks that matter when a peer behaves dishonestly, including scenarios in which a forwarding node could lose funds.
The release follows another security update, Eclair 0.14.4, published on October 15. Together, the changes cover both the rules used to move payments between channels and the interface through which operators control their nodes. The public notices reviewed do not quantify losses or establish that attackers exploited the newly described weaknesses in practice.
Why Lightning payment timing affects a node's funds
Eclair is one implementation of the Lightning Network, a payment system built around channels secured by Bitcoin. It uses Bitcoin Core to monitor the blockchain and manage on-chain funds. Other Lightning implementations have their own codebases, so an Eclair patch should not automatically be described as a vulnerability affecting every Lightning wallet.
A payment can pass through several channels before reaching its recipient. Conditional payments called hashed timelock contracts, or HTLCs, connect those steps. A recipient can claim a payment by supplying the required secret and signature; a sender can recover it after the relevant deadline if it remains unclaimed.
The deadlines must leave each forwarding node enough time to collect its incoming payment after paying the next participant. That timing is part of the protection behind the transfer. If a channel dispute moves settlement onto the blockchain, the node still needs a workable sequence for collecting what it is owed.
The routing fix preserves the order of payment deadlines
One fix concerns trampoline routing, in which a node helps find the onward route for a payment. ACINQ's October 20 code review describes a retry behavior that could relax the permitted payment-expiry limit after an initial route search failed.
The consequence was more serious than a failed payment. An outgoing payment could remain claimable after the corresponding incoming payment expired. A dishonest payer could then recover the incoming funds while the final recipient still collected the outgoing funds, leaving the forwarding node to absorb the difference.
The revised behavior retains the expiry restriction during retries, while allowing the route-length limit to change. The node can search further without abandoning that protection.
A second fix checks channel-funding information against Bitcoin
Another October 20 change concerns splicing, a way to change a channel's funding without treating it as an entirely new payment relationship. In the affected taproot-channel flow, a peer could provide an input's claimed amount and spending script without supplying the full previous transaction.
ACINQ's explanation says Eclair had not checked those details against the actual blockchain output. False information could make the node sign a splice transaction that could never confirm, while its local channel state nevertheless treated that transaction as the latest funding arrangement.
That mismatch could leave a forwarding node unable to collect an incoming payment while a peer used the previous funding state to claim outgoing funds. The fix obtains the previous transaction from Eclair's Bitcoin backend and rejects inconsistent output information.
The broader point for readers comparing layer 2 networks and their security assumptions is that access to the base blockchain is useful only when the software checks and applies that information correctly.
The earlier update also changes browser integrations
Operators upgrading from before version 0.14.4 must also account for a change to Eclair's application programming interface, or API. That release rejects requests carrying an Origin header, preventing direct API use from a web browser.
The project explains that browsers can reuse cached HTTP Basic authentication credentials in requests initiated by another website. This created a route for a page visited by the operator to trigger an authenticated action. Rejecting those browser requests closes that route, but it also changes how browser dashboards must connect.
Command-line access is unaffected, according to the release notes. Browser-based integrations now need their own backend between the user interface and Eclair. Operators should check that dependency alongside the node upgrade.
What operators and ordinary holders need to distinguish
ACINQ's upgrade instructions do not require channel closure. Operators can stop Eclair, install the new release and restart, with signature and checksum verification available on its release page.
Eclair's documentation separately requires backups of both the Bitcoin Core wallet and Eclair channel data. Those are different records with different roles, an important distinction within wallet custody and recovery.
The evidence supports an upgrade priority for Eclair operators, especially those forwarding payments or maintaining integrations. It does not establish how many deployed nodes remain exposed, prove that funds were stolen, or justify telling every person holding bitcoin to move their coins. The actionable development is the released software correction and the specific operational changes accompanying it.