Eclair's channel-opening DoS bugs: how the drain worked

Two denial-of-service flaws in Eclair, a Lightning Network node implementation maintained by ACINQ, let a single remote peer drain a node's memory during channel opening. According to Bitcoin Optech, which summarised the disclosure in its newsletter #427, both bugs were fixed in version v0.14.1 in July. This article looks at how each flaw worked, why such small mistakes had such large effects, and who needs to act.

The change in one paragraph

Erick Cestari posted a responsible disclosure on the Delving Bitcoin forum describing two bugs in the way Eclair handles requests to open a new payment channel. Both affect Eclair v0.14.0 and every earlier release. The fix landed in Eclair #3324 and shipped in v0.14.1 in July. Bitcoin Optech's advice is direct: "users running an older version should upgrade". A denial-of-service, or DoS, attack does not steal funds. It knocks a node offline by exhausting a resource such as memory or CPU, and an offline Lightning node cannot route or receive payments.

Under the hood: a race and a broken counter

Opening a Lightning channel starts with an open_channel message. Because the funding transaction does not exist yet, the channel is labelled with a temporary_channel_id. Once funding is set up, it receives a final channel_id. Eclair keeps some state in memory for each channel being negotiated, and it caps how many channels can sit in the pending state, meaning their funding transaction is not yet confirmed.

The first flaw was found by Matt Morehouse with his smite fuzzer, a tool that throws large volumes of unusual input at software to find crashes. It was a race condition. Eclair checked that a temporary ID was unused before accepting an open_channel request, but only recorded the new channel at a later step. Several identical requests sent in quick succession could all pass the check before any was recorded.

The second flaw, found by Cestari, defeated the pending-channel cap. Since the duplicate guard examined temporary IDs alone, a peer was free to take a channel's final channel_id and present it as the temporary ID of its next request.

• Race bug: Eclair built two channel states under a single ID, and the later one replaced the earlier. The orphaned copy, about 25 kB, lingered until the attacking peer dropped its connection. Repeated, this leaked roughly 1 MB per second.
• Counter bug: the limiter counted the recycled ID twice and later removed both entries, so its count stayed at two or below while real pending channels grew without limit.
• Amplifier: Eclair keeps the peer's init features alongside every pending channel. By flagging a single unrecognised odd feature far up the bit range, an attacker made that stored copy swell to about 65 kB.
• Persistence: Eclair saves pending channels to its database, so each restart reloaded the bloated state and brought the node down again, until an operator either gave it more memory or removed the stored entries manually.

Bitcoin Optech reported that Cestari's test drained 4 GB of node memory in about 48 minutes, using a single connection that cost nothing onchain.

Why small bugs became large outages

Both flaws follow patterns that recur across node software, and they are worth understanding beyond Eclair. The first is the check-then-act gap. When software checks a condition and acts on it in separate steps, an attacker who can send messages fast enough can squeeze between them. The usual cure is to make the check and the record a single step, so a second request sees the first one immediately.

The second pattern is a limit that trusts identifiers chosen by the other side. A cap is only as good as the key it counts by. If a peer can make two different channels look like the same entry, or make entries disappear early, the cap stops measuring what it was meant to measure.

The third lesson is cost asymmetry. Opening a channel normally ties up bitcoin onchain, which makes spam expensive. Here the attack stopped before any funding was needed, so the attacker paid nothing while the victim paid in memory. Peer-supplied data that is copied and stored, such as the feature bits, multiplied the damage. Finally, writing pending channels to disk turned a temporary outage into a crash loop, because the node reloaded the attacker's state each time it started.

Who is affected

Operators running Eclair v0.14.0 or older, whether routing nodes or merchant setups, are exposed to a remote peer able to send channel-opening requests. Users of mobile wallets that connect through an Eclair node acting as their Lightning service provider (LSP) are in a different position. Morehouse said Phoenix and similar wallets are not exposed, since ACINQ had already patched its own nodes months ago.

Status and next steps

The fixes are already released, so the main step for operators is to confirm they run v0.14.1 or later. The same Bitcoin Optech newsletter also lists further Eclair changes, #3396, #3397 and #3400, which close ways a malicious peer could stop Eclair from enforcing HTLCs onchain during splicing. An HTLC is the conditional payment that carries a Lightning payment hop by hop, and splicing resizes a channel without closing it. Together, these fixes show how much of Lightning security depends on careful handling of messages from untrusted peers.

Sources

• Bitcoin Optech, 16 Oct 2026

AI wrote this summary from the primary documents and reports cited above. It went live automatically after checks that figures match those sources and nothing is copied; there was no human review. It explains a protocol or rule change and is not investment advice.