Disclosure: DoS vulnerabilities fixed in Eclair v0.14.1

These vulnerabilities are essential for users and operators to understand to ensure the security and functionality of their nodes.

The first vulnerability identified as LNF-2026-0003 involves a denial-of-service (DoS) exploit related to the channel opening process. This flaw occurs due to a race condition where sending duplicate temporary_channel_ids in rapid succession can bypass initial security checks. This issue allows an attacker to initiate multiple channel actors for a single temporary_channel_id, leading to potential severe memory leaks that could incapacitate the node by exhausting Java Virtual Machine memory or triggering critical garbage collection issues. The discovery was made possible through fuzz testing with a tool named smite, which scrutinized Eclair’s funding flow. More details on this vulnerability can be found in the lnfuzz advisory.

The second vulnerability relates to the misuse of temporary_channel_id in creating unfunded channels. In this scenario, Eclair's PendingChannelsRateLimiter, which aims to prevent fake channel DoS attacks, fails when an attacker reuses a temporary_channel_id from a finalized channel for a new open_channel request. This failure enables the attacker to exhaust the node's resources, potentially causing the node to crash repeatedly until resolved by increasing the heap size or manually deleting problematic rows. This issue was uncovered using an LLM-based harness that analyses codebase entry points against BOLTs framework. Further exploration of this issue is detailed in Erick Cestari's blog.

In terms of user responsibility, particularly for non-technical users of mobile Lightning wallets like Phoenix, it is crucial to understand the upgrade processes. Users of these wallets do not need to perform upgrades themselves; instead, this responsibility lies with the operators of the Eclair nodes or backend systems that support these wallets. This clarification helps users understand their roles and ensures they are aware of what actions, if any, are required from them during such updates. Notably, ACINQ, the operator behind Phoenix, has already patched these vulnerabilities in their Eclair nodes, securing the system well ahead of potential exploits.