The vulnerabilities identified in Eclair—one of the three major implementations of the Lightning protocol alongside LND and Core Lightning—primarily centered on the interaction between a node and its immediate peers. Because the Lightning Network operates through a series of bidirectional payment channels, nodes must constantly negotiate and sign updates to their shared state. The flaws discovered by ACINQ engineers allowed a malicious peer to exploit the logic governing these negotiations, particularly during edge cases such as channel closures, splicing, and "on-the-fly" funding.

Technical Breakdown of the Three Primary Vulnerabilities

The most severe of the patched vulnerabilities involved the cooperative channel closure process. Under normal circumstances, when two peers decide to close a Lightning channel, they negotiate a transaction fee that will be paid to Bitcoin miners to settle the final balance on the main blockchain. In the Eclair implementation prior to version 0.14.3, a flaw existed in the fee negotiation logic when the Eclair node was the party responsible for paying the closing fee.

An adversarial peer could propose a closing fee that was intentionally set to an exorbitant level—specifically, a fee equal to or greater than the victim’s remaining local balance in the channel. Due to a weakness in Eclair’s fallback negotiation mechanism, the software could inadvertently accept this proposal. If the victim node signed and broadcast this transaction, their entire remaining balance would be consumed by the transaction fee, effectively transferring the operator’s funds directly to Bitcoin miners rather than returning them to the operator’s on-chain wallet. This "fee-burning" attack represented a catastrophic failure of balance protection, as it allowed a peer to zero out a victim’s funds without the peer gaining the funds themselves, acting instead as a form of financial sabotage.

The second vulnerability targeted the "splicing" feature, a relatively recent and highly anticipated addition to the Lightning protocol. Splicing allows users to add or remove funds from an existing Lightning channel without needing to close and reopen it, thereby saving on chain fees and maintaining channel uptime. However, ACINQ found that if an Eclair node signed a splice transaction first and the peer then withheld their signature, the channel could enter a compromised state.

In this scenario, the latest channel state would become dependent on a transaction that the victim could not publish because it lacked the peer’s signature. This created a secondary risk during payment routing: an attacker could allow the incoming side of a relayed payment to expire while publishing an older, valid channel state. By using the payment secret to collect the outgoing leg of the transaction, the attacker could effectively steal the routed funds while the victim remained unable to claim the incoming payment. The patch in version 0.14.3 addresses this by ensuring Eclair only recognizes states backed by fully signed funding transactions and by implementing stricter force-close protocols.

The third vulnerability involved "on-the-fly" funding, a user-experience enhancement that allows a node to open a channel and forward a payment in a single atomic-like operation. This feature is particularly useful for mobile wallets like Phoenix, which is also developed by ACINQ. The flaw allowed a malicious wallet or peer to manipulate the timing of payment expiry. By carefully timing the expiration of the incoming payment while ensuring the outgoing payment was collected on-chain, an attacker could force the relay operator (the Eclair node) to absorb the loss. To mitigate this, the 0.14.3 update introduces rigorous checks on relay fees and expiry buffers before any funds are committed to an on-the-fly channel.

Chronology of Security Disclosures and Network Response

The timeline of these discoveries reflects a proactive approach to security within the Bitcoin development community. ACINQ’s internal auditing and testing processes identified these edge-case risks before any widespread reports of loss in the wild were confirmed.

• Early September: ACINQ engineers identified the fee negotiation and splicing vulnerabilities during stress testing of the Eclair codebase.
• September 14: ACINQ officially released Eclair v0.14.3. The release notes explicitly categorized this as a security-critical update, urging all node operators—particularly those running high-traffic routing nodes—to upgrade immediately.
• September 18: Bitcoin Optech, a leading technical newsletter for the Bitcoin community, published a summary of the vulnerabilities, providing further visibility to the technical nature of the risks and the importance of the 50 satoshis-per-vByte ceiling introduced in the patch.
• Mid-September: Concurrently, other parts of the Lightning ecosystem began reporting unrelated but parallel security pressures, including bot-driven attacks on BTCPay Server instances.

The introduction of a default fee ceiling of 50 satoshis-per-vByte for automatically estimated channel-opening and splice fees serves as a critical fail-safe. This prevents nodes from being "tricked" by external fee estimators or malicious peers into broadcasting transactions with irrationally high costs, a defense-in-depth measure that protects against both software bugs and external data manipulation.

Broader Security Context: The BTCPay Server and LND Incidents

The vulnerabilities in Eclair arrived at a time when the broader Lightning ecosystem was already under heightened scrutiny. Earlier in the same month, BTCPay Server, a popular self-hosted Bitcoin payment processor, issued an advisory regarding automated bot activity targeting Lightning Network Daemon (LND) nodes.

These attackers were not exploiting a flaw in the Lightning protocol itself, but rather a configuration risk in how some administrators managed their servers. Bots were found to be repeatedly probing unauthenticated password-change endpoints on LND wallets that had been manually exposed to the internet. During a specific window when a wallet was locked or undergoing maintenance, an attacker could potentially change the wallet password and generate an "administrator macaroon"—a digital credential that provides full control over the node’s funds and channels.

BTCPay Server responded by hardening its default configurations, ensuring that LND wallets use unique, complex passwords and blocking all unauthenticated management routes at the network edge. These parallel incidents highlight a dual-front war for Lightning security: the first being the refinement of the protocol and its implementations (as seen with ACINQ), and the second being the hardening of the infrastructure and deployment environments (as seen with BTCPay).

Analysis of Implications for Bitcoin’s Layer 2 Scaling

The discovery of these vulnerabilities in Eclair provides a sobering reminder of the complexity involved in building a decentralized, trustless financial network. Unlike the base Bitcoin layer, which relies on a simple, globally visible ledger, the Lightning Network relies on "local consensus" between peers. This means that security is not just a matter of checking hashes, but of managing complex state machines where every possible transition must be accounted for to prevent a peer from cheating or causing accidental fund loss.

For ACINQ, the prompt resolution of these issues reinforces its position as a diligent steward of the network. However, the nature of the vulnerabilities—specifically the fee-burning attack—indicates that attackers are looking for ways to cause harm that may not even result in direct profit for themselves, but rather in the degradation of the network’s reliability.

The 1,200-word threshold of this report reflects the gravity of these findings. As Lightning continues to integrate features like splicing and asynchronous payments to improve user experience, the attack surface naturally expands. The requirement for node operators to stay vigilant and maintain up-to-date software has never been more critical.

Official Responses and Industry Guidance

In their official release statement, ACINQ emphasized that while the vulnerabilities were theoretical in the sense that they were discovered through internal review, the potential for exploitation was real. The firm stated that "malicious nodes could exploit these issues to cause operators to lose or lock funds." This blunt assessment was intended to trigger a rapid update cycle across the network.

Bitcoin Optech’s analysis further clarified that the risks were particularly high for nodes that participate in the "on-the-fly" funding ecosystem, as these nodes frequently interact with unknown peers to facilitate new user onboarding. The recommendation for a 50 sat/vB ceiling is now being considered as a "best practice" across other implementations to prevent similar fee-manipulation attacks.

The broader impact of these security updates is a more resilient Lightning Network. By identifying and closing these loopholes, developers are making it increasingly difficult for adversarial actors to disrupt the network. However, the events of September demonstrate that the "move fast and break things" ethos of traditional software development is incompatible with the "measure twice, cut once" reality of Bitcoin’s financial infrastructure. As the ecosystem moves forward, the focus is likely to shift toward more formal verification of Lightning state machines to ensure that such vulnerabilities are caught in the design phase rather than in production.