Old Lightning nodes may be exposed to a full-channel wipeout after LND fix lands later than disclosed

LND, a Lightning Network node implementation, has disclosed a channel-close flaw that can put an entire channel balance at risk in the reproduced maximum-loss scenario. Operators using standard releases below 0.21.0 should treat their nodes as lacking the official fix unless they were independently patched.

The Aug. 13 disclosure describes how a malicious channel peer could combine a one-block Bitcoin reorganization with an old, revoked commitment transaction after a cooperative close. Bastien Teinturier, who published the disclosure, said no affected users were known.

Before the fix, LND could forget a cooperatively closed channel after the closing transaction received its first on-chain confirmation. That removed the channel state the node needed to respond safely if Bitcoin later reorganized that block out of the chain.

The attack requires more than an ordinary one-block reorganization. A malicious peer must first participate in the cooperative close, wait for one confirmation, and then take advantage of a reorganization that removes the closing transaction. The peer must also possess and publish an earlier revoked commitment, an outdated channel balance state that should trigger punishment.

An affected LND node can then fail to broadcast the penalty transactions designed to punish publication of that revoked state. Under the reproduced scenario, the loss can reach the channel’s full balance. That figure is a maximum loss condition, not evidence that the vulnerability was exploited in the wild.

The disclosure and fix are specific to LND. They do not suggest that other Lightning implementations share the same channel-close flaw.

The official fix starts with LND 0.21.0

Upstream repository history places the official fix in 0.21.0, not the 0.20.0 version cited by the public disclosure.

Pull request #10331 merged into the project’s master branch on Jan. 16, 2026. A backport to the 0.20.x branch was later reverted, and a subsequent documentation change said the improved cooperative-close confirmation logic had actually landed in 0.21.0. The project’s 0.21.0 release notes also associate the reorganization-safe close logic with that release line.

Operators therefore should not rely on the disclosure’s 0.20.0 cutoff. Standard releases below 0.21.0 should be treated as lacking the official fix unless independently patched.

LND’s security policy recommends the latest minor release of the newest major line an operator can support. As of Aug. 25, the project’s latest official package was lnd v0.21.2-beta, released Aug. 13.

The fix makes LND retain close state while waiting for multiple confirmations and react to reorganization notifications instead of considering the channel resolved after one block.