Two months after Lightning Labs disclosed a batch of LND security flaws on 11 August, 71% of the 550 public Lightning Network nodes then running an exposed LND release were still on one, according to a preprint by Saurabh Kumar of Bitcoin Data Labs, with data up to 13 October. That 71% is a share of the exposed group and not of the network. Those nodes were 14.9% of live LND nodes and held 6.4% of live LND channel capacity.
The figure is one researcher’s inference from public data, posted on arXiv on 21 October and not peer reviewed. We found no independent re-measurement. No theft linked to these LND flaws appears in the paper or in the Lightning Labs advisories.
In round numbers, about 390 of the 550 nodes stayed put (our arithmetic from the paper’s percentages). Another 10% had moved to a newer release line, and 20% no longer counted as live. The shares add up to 101% because they are rounded. The fixes were old: LND 0.19.0-beta shipped on 22 May 2025, 446 days before the advisories appeared.
How the study decides which LND nodes are exposed
LND is the software behind most public nodes on Lightning, the payment layer built on top of bitcoin (our guide to layer 1 and layer 2 networks explains the split). Lightning gossip, the messages nodes use to announce themselves, carries no software version. So nobody can simply count versions, as crawlers do on the Bitcoin peer-to-peer network.
Kumar’s workaround uses feature bits, the flags each node announces. He built a table of the bits set by every release of LND, Core Lightning (CLN), Eclair and LDK, then matched it against 814 daily snapshots of the public graph taken by his own LND node from May 2023 to the 13 October cutoff. The result is a “release line” for each node, which can span several versions. Patch releases inside a line cannot be seen.
The 550 is the size of a precise group, shown in the paper’s Figure 7: LND nodes that were live on a line older than 0.19 on the last snapshot before disclosure. “Live” means a peer had enabled a channel towards the node and updated it in the previous 14 days. Unannounced nodes, including most mobile wallets, are outside the count. So is a managed fleet of small LND nodes that peaked at 1,781 live nodes and was excluded because its nodes move together. Counting that fleet would have lowered the 14.9% to 12.9%.
Checking the method is harder for LND than for CLN. Some CLN nodes state their version in their alias, and there the inferred line was exact for 132 of 136 node and line pairs. No LND node in his data does that. For LND the paper relies on indirect tests: lines went backwards in only 0.7% of observed changes, and 97% to 99.7% of nodes that moved right after a platform shipped a new LND line landed on the line it shipped.
Kumar lists the weak spots himself. A node that upgrades without restarting, or whose new announcement never reaches the author’s node, keeps its old bits, and that pushes exposure upward. Operators can also switch features off so a newer line looks older. The paper’s strict bounds for disclosure day run from 5% to 15% of live LND nodes: the 5% counts only nodes whose every possible line is affected, so the 14.9% sits at the top of that range. In the other direction, 77% of the exposed nodes had signed a fresh announcement with the old bits in the 14 days before disclosure, so most were not stale entries.
The flaws range from denial of service to possible fund loss
Lightning Labs’ advisory index lists ten LND advisories dated 11 August, three rated T1 High and seven T3 Low. The paper groups six of them as denial of service. Those six are the T3 items fixed in 0.19.0, where a peer can exhaust a node’s resources or disrupt its gossip. One more flaw fixed in the same release is of a different kind.
That flaw is the HTLC first-stage sweep failure. HTLCs are the conditional payments that cross Lightning channels. On LND 0.18, a node with the default wallet reserve could skip the on-chain sweep of an outgoing HTLC above roughly 50,000 sats after a force close. A channel partner could route a large HTLC through the victim, force-close and claim the value once it timed out. Lightning Labs scores this as per-victim fund loss, and says the non-adversarial version of the bug was seen in the wild, with very high sweep fees and cascading force closes. The advisory reports no attack.
Older flaws sit behind the same 0.19 boundary. Security researcher Matt Morehouse disclosed on 4 December 2025 that LND 0.18.5 and below allowed attackers to steal node funds through a weakness in the sweeper. Two other T1 advisories of the August batch, the update_fee fee-burn exploit and the excessive HTLC failback, were fixed in 0.18.3 and 0.18.0, and only about 4% of live LND nodes remained on the releases concerned at the cutoff.
| Flaws | First disclosed | Fixed in | Live LND nodes exposed at disclosure (capacity) | On 13 October (capacity) |
|---|---|---|---|---|
| Six denial-of-service flaws in gossip, peer and queue handling, rated T3 Low | 11 Aug 2026 | 0.19.0 | 15% (6%) | 13% (6%) |
| HTLC first-stage sweep failure, rated T1 High, possible fund loss | 11 Aug 2026 | 0.19.0 | 10% (5%) | 8% (6%) |
| Replacement stalling and two other flaws reported by Matt Morehouse | 4 Dec 2025 | 0.19.0 | 28% (12%) | 13% (6%) |
| Excessive HTLC failback, rated T1 High | 4 Mar 2025 | 0.18.0 | 20% (8%) | 4% (0%) |
| Out-of-memory via Brontide write allocations, rated T3 Low | 21 Sep 2026 | 0.20.0 | 22% (11%) | 20% (10%) |
| Too few confirmations on cooperative close | 13 Aug 2026 | 0.21.0 | 51% (53%) | 33% (28%) |
Source: Kumar preprint, Table III, ratings from Lightning Labs. Exposure counts live LND nodes on an affected release line, managed fleet excluded, each row on its own disclosure day. The last two rows show why 0.19 is not a finish line.
How much bitcoin is exposed is unknown
The paper gives shares for the exposed nodes, not amounts, and we have not converted them into dollars. Its main capacity figure is 6.4% of live LND capacity on disclosure day. For scale only, it puts all live LND capacity at 8,300 BTC on 7 December 2025, a different date. The exposed nodes are small: their share of capacity is about half their share of nodes. For the fund-loss sweep flaw alone, which touches only the 0.18 line, the paper puts exposure at 10% of live LND nodes and 5% of capacity at disclosure.
A node on an affected line is not automatically attackable. “Exposure is not exploitability,” the paper says in its list of limitations. Several advisories need a channel with the victim, a particular configuration or inbound connections. The paper does not count how many of the 550 meet those conditions. Kumar still makes the small-node point from the other side: the capacity share is low, he writes, “but each holds its operator’s funds”. He adds that where an attack needs a channel with the victim, these nodes are also the cheapest to reach.
Core Lightning is a separate matter. The paper says the project’s maintainers reported attacks on unpatched CLN nodes by October. That statement is the paper’s, we have not confirmed those attacks elsewhere, and it concerns different software: it is no evidence that any LND node has been attacked.
Nothing we read links these LND flaws to the BTCPay Server hot wallet thefts we reported earlier on Monday, which concern wallets on merchants’ own BTCPay servers.
Lightning nodes upgrade when platforms ship, not when advisories land
The more durable finding is about behaviour. Half of LND nodes on an older line moved to a new release within 88 days. The smallest quarter by capacity took a median 135 days, the largest quarter 75, and nodes already more than one line behind had about five times lower odds of moving in any given week.
The three largest upgrade waves, 262 to 385 nodes each, came about a day after the Umbrel app store published a new LND version. At least 87% of those nodes signed a new announcement within 48 hours of Umbrel’s merge, and Umbrel’s releases trailed LND’s own by 19 to 41 days. Since June 2025, 17% of LND upgrades fell in the 48 hours after a platform release, windows covering 4.4% of the time. Those are lower bounds, because only Umbrel and BTCPay Server could be dated, and gossip does not name the platform a node runs on.
Advisories did far less. The weekly rate at which nodes left the affected lines was 1.4% both before and after 11 August. The paper is careful here: with the moves that followed BTCPay’s 7 August security release removed, the ratio is 1.30 with a 95% interval of 0.56 to 3.03, so a modest effect cannot be ruled out. Across the 12 disclosures it could test, nine of them for LND, only CLN’s of 19 July clearly sped up upgrades, and only among nodes one line behind.
Kumar’s likelier explanation is timing. The CLN gossipd fix was 90 days old at disclosure, and CLN exposure then fell from 66.6% of live nodes to 24.2% by the cutoff, with 46% of those nodes upgrading and 32% no longer live. LND’s fix was 446 days old, so the nodes left to warn were those that had skipped every release since. The median gap between fix and disclosure across the advisories studied is 256 days, a delay meant to let operators upgrade before attackers learn what to look for. An earlier cohort tells the same story: of 1,284 LND nodes exposed to Morehouse’s December disclosure, 55% were still on an affected line four months later.
What LND node operators can check now
Most mobile Lightning wallets were outside this study, so it says little about their users. Anyone running a public LND node can read the version directly on the machine, which no gossip inference can beat.
Lightning Labs’ advisory asks users to update to v0.19.0-beta or later, which clears the seven flaws fixed in that release. That is a floor. Under the company’s life cycle policy only the two newest lines are maintained, currently 0.21 and 0.20. The 0.19 line reached end of life on 5 June 2026, when 0.21.0 shipped, and gets no further security fixes. Advisories of 21 September already list flaws affecting 0.19 with fixes only in the 0.20 line or later.
The two maintained lines are not identical either. The cooperative-close flaw in the table lets a counterparty publish a revoked commitment after a one-block reorganisation, with funds at risk, according to the disclosure by Bastien Teinturier, who knows of no affected user. His post dates the fix to “20.0”. LND’s release notes list it under 0.21.0, as the paper does, and the code that change added is absent from the v0.20.7 tag when we read it on 2 November. On that reading, only the 0.21 line has it.
The latest LND releases, v0.21.6-beta and v0.20.7-beta of 30 October, also disable MPTCP listeners by default against the Linux kernel flaw CVE-2026-98432. The release notes call that a mitigation and say the kernel patch is the only fix. They ask Linux operators to disable MPTCP on the host as well and to install a patched kernel once their distribution ships one; Windows and macOS are not affected. Operators on Umbrel or similar boxes get LND when the platform ships it, so the app store version is the one to check.
Eclair users have a separate job. The browser-request flaw fixed in October also needed an operator to act, and the current release is now v0.14.6 of 27 October, which ACINQ describes as security hardening and recommends installing.
What would confirm or undercut the 71%
The author says code and aggregate data are public, along with a script that recomputes every number, while raw daily snapshots are available on request. An independent run from a second vantage point, or peer review, would test the figure. A statement from Lightning Labs or Umbrel would help too: we found none on the paper in the sources we opened. Kumar publishes aggregates only, with no list of individual nodes, because his method identifies nodes running vulnerable software.