Linux Kernel Flaw Triggers Emergency LND MPTCP Mitigation

Security researcher Marcus Hutchins reported roughly 2.1 million servers reachable over Multipath TCP (MPTCP) on port 443 amid scanning activity consistent with threat actors seeking exposed systems. The target was CVE-2026-98432, a Linux kernel IPv4 TCP-handshake flaw assigned a CVSS severity score of 9.8.

Bitcoin Core and Lightning developer Matt Corallo highlighted the flaw on October 30, criticizing Ubuntu’s delayed response and calling it “the most critical Linux vuln ever.” Anthropic’s Frontier Red Team later showed that the bug could be turned into a remote-root exploit against systems exposing an MPTCP listener.

Peter Todd echoed the warning that day and advised anyone running LND on Linux with open ports to shut down their Bitcoin Lightning nodes until the kernel was patched or otherwise mitigated. The demonstrated exploit path relied on an MPTCP listener, which Go 1.24 and later enable by default.

Because LND is written in Go, recent versions listened with MPTCP on their peer, gRPC and REST ports whenever the host kernel supported the feature. That widened the internet-facing attack surface for nodes exposing those interfaces, even though the defect resides in the kernel rather than LND.

What does this change for Lightning node operators?

Lightning Labs issued emergency releases the same day: lnd v0.21.6-beta and the v0.20.7-beta backport. Both disable MPTCP listeners by default, closing the demonstrated exploit path through LND. The project described the change as a mitigation, not a fix, and said only a patched kernel fully resolves the underlying issue.

Operators should install the relevant release and update the host kernel. The software update removes LND’s specific MPTCP listener path, but it does not protect unrelated services on the same host. Those services remain exposed until MPTCP is disabled host-wide or the kernel is updated.

Olaoluwa Osuntokun and the official Lightning Labs account both recommended the update. For operators sharing a server, the application fix is not equivalent to host-wide remediation: another daemon can keep an MPTCP listener open after LND stops doing so.

Where kernel patches stand

Canonical has made fixed kernels available in the opt-in proposed pocket for Ubuntu 22.04, 24.04 and 26.04, but has not yet placed them in the regular updates channel. Red Hat shipped fixes for RHEL 8, RHEL 9 and RHEL 10 on November 1. Debian, Amazon Linux and other distributions had released patches earlier.

UmbrelOS 2.0.1 included the kernel fix on November 1 for x86 devices. On Raspberry Pi, where a fixed kernel was not yet available, Umbrel applied a traffic-blocking mitigation. International Cyber Digest amplified Hutchins’s scanning finding on November 4, alongside criticism of Ubuntu’s slower patch timeline.

Exposure is highest on internet-facing servers. Home desktops behind typical network address translation and firewalls, without public TCP listeners, face materially lower risk. For Lightning operators, an LND release and a patched kernel address separate layers: the first closes the demonstrated service path, while the second removes the underlying kernel flaw.

What remains unconfirmed

No report has confirmed exploitation in the wild, and CISA has not added the vulnerability to its Known Exploited Vulnerabilities catalog. Hutchins’s 2.1 million-server count measured reachability, not successful compromise. The distinction matters because exposed MPTCP services can be scanned and probed before any confirmed exploit appears in the wild.

Anthropic’s remote-root demonstration remains unpublished, leaving operators without a public proof of concept from the cited research. The immediate defensive choices are the LND emergency release, a patched host kernel, or disabling MPTCP host-wide.

The next material checkpoint is Canonical moving fixed kernels from the proposed pocket into regular Ubuntu updates; until then, exposed hosts must rely on an LND release, a directly installed kernel fix, or host-wide MPTCP controls.