Bitcoin Lightning’s security update shuts one door. A critical Linux flaw remains

Bitcoin Lightning operators running an affected, unpatched Linux kernel remain exposed to a critical vulnerability after upgrading LND, the software used to operate their payment nodes.

Its October 30 releases, v0.20.7-beta and v0.21.6-beta, disable Multipath TCP, or MPTCP, listeners by default. That closes the demonstrated CVE-2026-98432 route through those listeners. It leaves the kernel flaw in place and does not cover other services on the same machine.

Another exposed MPTCP service on the same unpatched machine can preserve the demonstrated route, even after LND's default listeners have changed.

Why the LND update has limits

The flaw involves freed memory being used during IPv4 TCP connection handling in Linux and can allow an attacker to run code on an affected host. Ubuntu assigns it a critical CVSS 3.1 score of 9.8.

LND's operator notes say Go 1.24 and later enabled MPTCP listeners by default on Linux, which LND 0.21.x consequently exposed on its peer, gRPC and REST ports. These include the node's connections to other nodes and its application interfaces.

The Go Security Team's advisory explains why that change cannot finish the job. The demonstrated exploit requires an exposed MPTCP listener, but the kernel bug is broader. Similar attacks against systems without MPTCP listeners may be possible; the advisory does not establish a demonstrated non-MPTCP exploit.

Go also warns that disabling MPTCP one program at a time is fragile. A single remaining exposed listener leaves the system vulnerable to that route, and explicit socket settings can override Go's default configuration.

The advisories describe a demonstrated Linux exploit, not evidence that attackers used this flaw against LND nodes or stole Bitcoin.

CryptoSlate previously covered the same CVE's implications for Solana validators. The Core Lightning channel and remote-command fixes reported November 6 concern separate application flaws.

The Ubuntu tracker, checked November 9 and last updated November 7, still labeled the standard linux package for Ubuntu 24.04 LTS vulnerable, with work in progress in 6.8.0-149.149. Its Ubuntu 22.04 LTS entry carried the same status for 5.15.0-203.213.

Patch availability varies by package. In its November 2 advisory, Canonical said kernel fixes for this CVE were available in the -proposed repository for users who run their own kernel acceptance tests, while qualification testing continued.

Ubuntu's work-in-progress newsletter for November 1--7 also said some releases, including 24.04, had advanced to -updates. That broader note does not identify every kernel variant. Operators therefore need to check the available update for their exact kernel package rather than infer availability from the Ubuntu release name alone.

The tracker illustrates the distinction: it lists the standard Ubuntu 26.10 linux package as fixed in 7.3.0-10.10, while cloud, hardware-enablement and other kernel variants have separate entries. A fixed status for one package cannot settle the status of another.

Protection still requires work on the host

LND maintainers recommend upgrading the application, disabling MPTCP on the host, and installing a patched kernel as soon as the distribution makes one available.

LND closes a route. The kernel still needs repair.

LND's update changes the application. Repairing the shared Linux kernel requires a separate host update.
ONE HOST, TWO MAINTENANCE LAYERS LND Application release Other services Separate applications Shared Linux kernel
LND Other services Shared Linux kernel

Cumulative host configurations

Cumulative host configurationsLND updatedMPTCP offPatched kernel running
Illustrative configuration: LND's default MPTCP listeners are off, but another service still exposes one on an unpatched host.
Incoming MPTCP traffic LND Default MPTCP off Other service MPTCP exposed SHARED LINUX KERNEL Kernel flaw remains Host kernel still unpatched
Incoming MPTCP traffic LND Default MPTCP off Other service MPTCP exposed SHARED LINUX KERNEL Kernel flaw remains Host kernel still unpatched One other listener preserves the route.
With MPTCP disabled across relevant network namespaces, the demonstrated route is closed. The underlying kernel flaw remains.
Incoming MPTCP traffic LND Default MPTCP off Other service MPTCP disabled SHARED LINUX KERNEL Kernel flaw remains Host kernel still unpatched
Incoming MPTCP traffic LND Default MPTCP off Other service MPTCP disabled SHARED LINUX KERNEL Kernel flaw remains Host kernel still unpatched MPTCP mitigation leaves the bug in place.
After a patched kernel is installed and booted, this kernel flaw is repaired. The diagram retains the preceding MPTCP mitigation.
Incoming MPTCP traffic LND Default MPTCP off Other service MPTCP disabled SHARED LINUX KERNEL This kernel flaw repaired Patched kernel is running
Incoming MPTCP traffic LND Default MPTCP off Other service MPTCP disabled SHARED LINUX KERNEL This kernel flaw repaired Patched kernel is running Repair applies to this kernel flaw.

Upgrade LND, address other MPTCP listeners and network namespaces, then install and boot a patched kernel.

Illustrative configurations, not tests of a live node or a record of attacks. Disabling MPTCP covers the demonstrated route only; the bug is broader. The disabled state assumes relevant network namespaces are covered. Other vulnerabilities are outside scope.
Sources and evidence

Sources

1. LND v0.20.7 security release
2. LND v0.21.6 security release
3. LND operator and Docker guidance
4. Go Security Team advisory
5. Canonical kernel update and reboot guidance

Supporting facts

• LND v0.20.7-beta and v0.21.6-beta, released October 30, disable MPTCP listeners by default to close the demonstrated CVE-2026-98432 exploit path through LND; they do not repair the Linux kernel. [1] [2]
• The Go Security Team says the demonstrated exploit requires an exposed MPTCP listener, but the underlying bug is not specific to MPTCP and similar attacks against systems without such listeners may be possible. [4]
• The Go Security Team warns that disabling MPTCP program by program is fragile: one remaining exposed MPTCP listener leaves the host vulnerable to the demonstrated route, and per-socket choices can override the GODEBUG default. [4]
• An LND upgrade does not protect other services on the same machine; LND maintainers advise disabling MPTCP on the host and installing a patched kernel as soon as the distribution ships one. [2] [3]
• LND's guidance uses sudo sysctl -w net.mptcp.enabled=0 and a persistent sysctl configuration to disable host MPTCP; the setting is per network namespace, so Docker deployments require separate namespace attention. [3]
• Canonical advises checking the running kernel with uname -r; after installing the Linux kernel security updates, a reboot is required. [5]

Method

Schematic of cumulative operator configurations using documented LND and Go behavior. Paths show the demonstrated MPTCP route, not Bitcoin transfers or measured traffic. The final state requires installing a patched kernel and rebooting into it.

Scope

Illustrative configurations, not tests of a live node or a record of attacks. Disabling MPTCP covers the demonstrated route only; the bug is broader. The disabled state assumes relevant network namespaces are covered. Other vulnerabilities are outside scope.
Infographic by CryptoSlate

Their guidance uses sudo sysctl -w net.mptcp.enabled=0 for the host setting, with a persistent configuration to retain it. The setting applies per network namespace, so Docker deployments need separate attention to the container's network configuration. Changing the host alone is not a substitute for checking that scope.

Operators who cannot upgrade LND immediately can start their existing binary with GODEBUG=multipathtcp=0 to disable Go's default MPTCP listeners. Maintainers warn against re-enabling that default before patching the kernel.

Canonical advises checking the kernel actually running with uname -r. After installing its kernel security update, a reboot is required. An upgraded LND binary and an installed kernel package are different milestones; completing the operating-system repair requires running the patched kernel.