Lightning Developers Disclose Fund-Loss Flaw Across Major Implementations

Lightning Network developers on September 27, 2019, fully disclosed a channel-funding vulnerability affecting major implementations of Bitcoin’s payment-layer software. The coordinated record assigned three identifiers—CVE-2019-12998 for c-lightning, CVE-2019-12999 for lnd and CVE-2019-13000 for Eclair—and explained how an attacker could induce a node to accept a channel that was not funded as promised.

The defect did not compromise Bitcoin’s consensus rules, blockchain or private-key system. It arose in software implementing Lightning, a separate network of payment channels designed to move bitcoin without recording every payment on the base chain. Its significance came from the potential for real losses at routing nodes and from its presence across several independently developed implementations.

How the channel flaw worked

Opening a Lightning channel requires a Bitcoin funding transaction. After that transaction receives the required confirmations, the receiving node must establish that the confirmed output is the precise output referenced by the channel’s commitment transaction and that its value equals the capacity proposed during negotiation.

The September 27 disclosure said implementations had omitted some or all of those checks. A malicious peer could therefore present a funding transaction that existed on the blockchain but did not create the promised spendable output, or created one containing less bitcoin than represented to the receiving node.

That mismatch became financially dangerous when the invalid channel was used to originate a routed payment. A victim could forward a valid payment through one of its other channels while believing it had received an equivalent incoming claim. Because the incoming channel lacked the expected backing, the victim could not recover that side of the transfer when closing the channel. Lightning Labs described the possible loss as approximately the value of the forwarded hashed timelock contracts involved, not the advertised capacity of every invalid channel.

Disclosure followed an upgrade window

The full explanation completed a staged process rather than announcing an unpatched zero-day. Rusty Russell had issued a limited warning on August 30, 2019, allowing operators time to upgrade before technical details became public. A September 10 update said instances of exploitation had been confirmed in the wild, but the public notices did not identify victims or establish an aggregate loss.

By September 27, the recommended protected releases were lnd 0.7.1, c-lightning 0.7.1 and Eclair 0.3.1. Lightning Labs said lnd 0.7.1 had fully patched its implementation and released a separate inspection utility, `chanleakcheck`, for determining whether an lnd node had accepted an invalid channel or forwarded payments from one.

For lnd operators unable to update immediately, Lightning Labs described disabling new inbound pending channels as a temporary mitigation. That reduced exposure to new malicious channel openings but was not presented as a substitute for upgrading.

Why the disclosure mattered

Lightning’s design depends on nodes enforcing both Bitcoin transactions and the additional promises made during off-chain channel negotiation. A base-layer transaction could be valid while still being wrong for the channel a peer claimed to have created. The incident showed why implementations had to validate that second relationship explicitly.

The cross-implementation scope also made the episode more consequential than an isolated client bug. Independent codebases had interpreted or enforced a critical channel-opening condition inadequately, revealing a shared assurance gap in infrastructure intended to carry monetary value. The coordinated patches and delayed technical disclosure demonstrated a functioning response process, but the confirmed-exploitation statement made clear that the risk was not merely theoretical.

No reliable event-day record quantified affected nodes, stolen bitcoin or market impact. Bitcoin price movements on September 27 therefore cannot responsibly be attributed to this disclosure from the available evidence.

Later record

The National Vulnerability Database published entries for the three CVEs on January 31, 2020. Those later records corroborate the implementation mappings and fund-loss risk, but they were not available for contemporaneous September 27 reporting.