LND Flaw Put Full Lightning Channel Balances at Risk, With Official Fix Only in 0.21.0

Operators of LND, a node implementation for Bitcoin's Lightning Network, should assume their nodes lack the official fix for a newly disclosed channel-close flaw unless they run version 0.21.0 or later, CryptoSlate reported.

In the reproduced worst-case scenario, the bug could cost a node its entire channel balance.

How the flaw works

Lightning channels let two parties exchange payments off-chain, updating a shared balance that is settled on Bitcoin when the channel closes. If both sides agree to close, they sign a cooperative closing transaction and broadcast it to the network.

Before the fix, LND could discard its record of a cooperatively closed channel once that closing transaction received its first on-chain confirmation. That left the node without the state it needed to react safely if a block reorganisation later removed the confirmed transaction from the chain.

Exploiting that gap takes several steps. A hostile channel peer would need to:

• take part in the cooperative close and wait for one confirmation;
• benefit from a one-block reorganisation that drops the closing transaction;
• publish an earlier, revoked commitment transaction, an outdated balance state the protocol is designed to punish.

Lightning's security relies on the honest party answering a revoked state with penalty transactions that claim the cheating party's funds. An affected LND node could fail to broadcast those penalties. In the reproduced scenario, the loss could reach the channel's full balance.

A version boundary that moved

Bastien Teinturier published the disclosure on the Delving Bitcoin forum on 13 August and said no affected users were known. CryptoSlate stressed that the full-balance figure describes a maximum-loss condition, not evidence that the flaw has been exploited.

The more pressing issue for operators is which releases are actually protected. The public disclosure cited LND 0.20.0 as the cutoff, but the project's repository history points elsewhere.

The relevant change, pull request #10331, was merged into the master branch on 16 January 2026. A backport to the 0.20.x branch was later reverted. A subsequent documentation change stated that the logic landed in 0.21.0, and the 0.21.0 release notes link the close-handling changes to that release line.

The practical conclusion is that standard releases below 0.21.0 should be treated as unpatched unless an operator applied a fix independently.

What the fix changes

The patched code has LND retain close state while it waits for multiple confirmations, instead of treating a channel as resolved after a single block. It also responds to reorganisation notifications, so a closing transaction that drops out of the chain no longer leaves the node unable to defend itself.

Under LND's security policy, operators are advised to use the newest major version they are able to support, updated to its most recent minor release. On 25 August, lnd v0.21.2-beta was the latest official package; it had come out on 13 August, the day the disclosure was published.

Limits and what to watch

The flaw is specific to LND. Nothing in the disclosure suggests that other Lightning implementations share it.

The attack is also demanding. It needs more than a reorganisation alone: the attacker must be a direct channel counterparty, must have cooperated in the close, and must hold a revoked state worth broadcasting. That narrows the realistic set of targets.

Still, the gap between the disclosed cutoff and the actual fix matters. An operator who checked a node against the 0.20.0 threshold may have concluded it was safe when it was not. On a network where security depends on nodes reacting correctly to on-chain events, accurate version guidance is basic hygiene.

The main things to watch are how quickly operators move to the 0.21 line and whether the version reference in the original disclosure is formally corrected.