Eclair, the flagship Lightning Network node implementation developed by the Paris-based technology firm ACINQ, has integrated two critical security repairs designed to mitigate vulnerabilities that could lead to significant financial losses through excessive mining fees. These vulnerabilities, which primarily affect nodes utilizing advanced features like dual funding, splicing, and remote signer configurations, represent a sophisticated class of risks where funds are not necessarily stolen by an attacker but are instead "burned" as exorbitant fees paid to Bitcoin miners. The patches, merged into Eclair’s master branch in early October 2026, address gaps in how the software handles peer-initiated fee adjustments and how it validates transactions constructed by potentially compromised backends.

The Lightning Network, a Layer-2 scaling solution for Bitcoin, relies on complex smart contracts and off-chain state updates to facilitate near-instant, low-cost payments. As the protocol evolves, features such as "dual funding"—where both parties contribute liquidity to a new channel—and "splicing"—which allows for the dynamic resizing of existing channels without closing them—have become integral to improving user experience and capital efficiency. However, these features also introduce new attack surfaces. The recent fixes in Eclair underscore the ongoing challenge of maintaining security as the protocol’s complexity increases.

The Mechanics of Peer-Initiated Fee Exploitation

The first major repair, identified as Pull Request (PR) #3388, addresses a vulnerability within the peer-initiated Replace-By-Fee (RBF) mechanism during dual-funded channel openings or splicing operations. Under normal circumstances, RBF allows a transaction sender to replace an unconfirmed transaction with a new version that includes a higher fee, ensuring faster confirmation during periods of network congestion.

In the context of Eclair’s previous implementation, a peer could initiate an RBF request during a collaborative transaction process. If the Eclair node was contributing funds to the transaction, it would honor the peer’s demand for a higher fee rate to ensure the transaction remained competitive in the mempool. The critical flaw was the absence of an upper bound or a pre-defined fee budget for these specific RBF paths.

A malicious actor could exploit this by repeatedly requesting fee bumps at astronomical rates. Because Eclair would automatically adjust its contribution to meet these rates without a secondary verification of the "reasonableness" of the fee, the node’s balance could be rapidly depleted. It is important to note that the malicious peer does not receive these funds; rather, the funds are distributed to Bitcoin miners as transaction fees. This type of "griefing" attack serves to drain a node’s operational liquidity, potentially forcing it offline or causing significant financial distress to the operator.

The fix implemented in PR #3388 introduces a strict rejection mechanism. Eclair will now decline any RBF attempts that exceed the maximum funding fee rate it recommends to its peer. The software maintains two logical exceptions to this rule: if the peer is explicitly purchasing liquidity and therefore assuming the cost of Eclair’s inputs, or if the Eclair node is not contributing any funds to the transaction. In these scenarios, the node is not at risk of losing its own capital to the fee-bump demand.

Strengthening the Eclair-Signer Security Model

The second repair, PR #3390, targets a more structural risk associated with "Eclair-signer" mode. In high-security environments, node operators often separate the transaction construction logic from the private keys. In this architecture, a Bitcoin Core backend (bitcoind) handles coin selection and transaction building, while Eclair retains the signing keys in a protected environment.

This separation is intended to ensure that even if the Bitcoin backend is compromised, the attacker cannot steal the private keys. However, PR #3390 highlights a subtle way a compromised backend could still inflict financial damage. Because Bitcoin transaction fees are calculated as the difference between the total value of inputs and the total value of outputs, a compromised backend could "lie" to Eclair about the actual fee being paid.

For example, a compromised bitcoind could report a fee that falls within Eclair’s configured budget while secretly constructing a transaction that omits a "change output"—the mechanism that returns unspent funds to the sender. In the Bitcoin protocol, any input value not explicitly assigned to an output address is automatically granted to the miner as a fee. By dropping the change output, a compromised backend could effectively spend an Eclair node’s entire balance on a single transaction fee.

The repair merged by ACINQ addresses this by introducing a "Zero Trust" approach to the backend’s data. Eclair now independently calculates the actual fee by fetching the values of the coins being spent directly from the blockchain via transaction IDs, ensuring their values are authenticated. The software then compares this calculated fee against the fee reported by the backend. If the figures do not match, or if the actual fee exceeds the pre-set budget, Eclair will refuse to sign the transaction. Additionally, the update includes checks to ensure that change-output positions are valid and that Eclair’s own rebuilt contributions match the verified fee structure.

Chronology of the Fixes and Release Status

The timeline of these developments reflects the rapid pace of security auditing within the Bitcoin Lightning ecosystem. According to the project’s GitHub repository, the repairs were merged into the master branch on October 2 and October 5, 2026. These updates followed closely on the heels of the Bitcoin Optech newsletter published on October 9, which provided a technical breakdown of the protection gaps in dual funding and splicing.

As of mid-October, the official release page for Eclair still lists version 0.14.3, which was released in September, as the latest stable version. This means that the October fixes postdate the current packaged release. Node operators who rely on pre-compiled binaries may not yet have access to these protections unless they build Eclair directly from the master branch or wait for the next formal release (likely v0.15.0 or a minor patch update).

This delay between "merge" and "release" is a standard part of the software development lifecycle, allowing for further testing in various environments. However, for institutional operators and high-volume routing nodes, the gap represents a window of vulnerability that requires active monitoring.

Contextualizing Recent Lightning Network Vulnerabilities

The discovery and mitigation of these fee-related flaws are part of a broader trend of hardening the Lightning Network against sophisticated "non-theft" attacks. These fixes follow several other notable security concerns addressed by the ACINQ team and the wider developer community in recent months:

1. Cooperative-Closing Fee Flaw: In September 2026, reports surfaced regarding a flaw in how cooperative channel closures handled fees. Similar to the current RBF issue, this could allow a counterparty to influence the fee of a closing transaction to the detriment of the other party.
2. Restart Denial-of-Service (DoS): In early October, Eclair addressed an issue where unpatched nodes could be forced into a crash loop every time they attempted to restart, a vulnerability that could be triggered remotely by a malicious peer.
3. Channel Jamming: While not specific to Eclair, the industry-wide effort to mitigate channel jamming—where attackers tie up liquidity with "HODL invoices"—continues to influence how node software manages peer reputations and transaction limits.

By addressing the dual-funding and splicing fee gaps, Eclair is moving toward a more resilient implementation that assumes peers and even local backends may behave maliciously or be compromised.

Broader Implications for the Bitcoin Ecosystem

The transition of the Lightning Network from an experimental "alpha" phase to a robust financial infrastructure requires the elimination of "foot-guns"—features that, while functional, can be easily misused to cause financial loss. The fixes in PR #3388 and PR #3390 represent a significant step in this direction.

For the broader Bitcoin ecosystem, these developments highlight the importance of independent verification. The fact that Eclair now verifies the work of its Bitcoin backend (bitcoind) suggests a shift in the security paradigm. It is no longer sufficient for a Layer-2 node to trust its Layer-1 interface blindly. This "verification-in-depth" approach is likely to become a standard requirement for all Lightning implementations, including Core Lightning (CLN) and LND, as they adopt similar advanced features.

Furthermore, the focus on "fee-burn" attacks serves as a reminder that the cost of network security (miner fees) can be weaponized. As Bitcoin’s block subsidy continues to decline with each halving, the fee market will become increasingly volatile and competitive. Ensuring that automated systems like Lightning nodes can navigate this market without being tricked into overpaying is essential for the long-term economic viability of the network.

Recommendations for Node Operators and Developers

In light of these updates, node operators using Eclair are encouraged to review their configurations, particularly if they have enabled dual funding or splicing features. While the risks described require a malicious peer or a compromised backend to execute, the potential for loss is high.

Operators should:

• Monitor Release Notes: Keep a close watch on the ACINQ Eclair GitHub repository for the announcement of version 0.14.4 or 0.15.0, which will formally package these repairs.
• Assess Backend Security: For those running Eclair-signer mode, the security of the host machine running bitcoind remains paramount, even with the new verification checks in place.
• Audit Peer Connections: Use reputation-tracking tools to monitor the behavior of channel peers, looking for patterns of excessive RBF requests or fee-bump demands.

The proactive merging of these fixes by the ACINQ team demonstrates a commitment to the "Safety First" ethos of the Bitcoin community. As the Lightning Network continues to grow in both capacity and complexity, the ability to identify and close these subtle financial gaps will be the hallmark of a mature and reliable payment protocol.