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

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.

Related Reading

Researchers discover vulnerabilities in Bitcoin layer-2 Lightning Network

Binance

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.

Related Reading

Inside Bitcoin’s 24 hour race to survive a global internet blackout

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 Daily Brief

The signal, before the noise.

Start your day with the crypto stories moving markets, decoded by CryptoSlate’s editors.

One email. Everything that matters.

Free to join. Unsubscribe any time.

Whoops, looks like there was a problem. Please try again.

You’re on the list. Your next Daily Brief is on its way.

Six-step LND channel-close exploit sequence showing the one-block reorganization prerequisite, full-channel maximum loss, and upgrade cutoff at version 0.21.0.

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

Related Reading

Exchange BTC Lightning channels break our favorite Bitcoin metric

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.



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *

Pin It on Pinterest