How to Protect Your Bitcoin Node From Linux Kernel Flaw CVE-2026-98432

A race condition in the code Linux uses to accept new TCP connections over IPv4 can, at worst, let a stranger run commands as root on your machine without a password. Nearly every kernel since 4.4 carries it. Debian has patched. As of October 31, 2026, Ubuntu, Red Hat and Umbrel had not. Here is how to work out whether your node is exposed, how to check it, and what the official sources say to do in the meantime.

The Linux kernel's CVE team published CVE-2026-98432 on October 15, 2026 [1]. For twelve days it was one more line in a long list of kernel fixes. Then, on October 27, Anthropic's Frontier Red Team described how an unreleased internal model had written a working remote exploit for it, one that runs an attacker's command as root on a Linux server just by sending it packets [4]. By October 30 the warning had reached Umbrel's issue tracker, the Start9 forum and Lightning operators' channels [16][19][21].

A bitcoin node is a machine whose whole job is to accept connections from strangers. That is exactly the part of the kernel this bug lives in.

Who should move first

• VPS and servers with a public IP address. Every listening port is reachable by anyone. If the box also runs LND older than 0.21.6 or 0.20.7, it matches the conditions of the demonstrated exploit [13].
• Home nodes with ports forwarded on the router. That covers 8333 for Bitcoin Core, 9735 for Lightning and 50002 for an Electrum server. A Lightning node that advertises a clearnet address also shows up in public network gossip, a point made in the LND issue that first raised the problem [14].
• Tor-only home nodes. Nobody on the internet can send packets straight to them, and a community developer who builds for Start9 and Umbrel considers them out of reach of this attack [21]. Anything already on your local network still can, from a compromised laptop to a badly secured smart device.

Wherever you land on that list, every official source ends with the same instruction. Install a fixed kernel and reboot.

What the bug is

When a Linux machine receives a request to open a TCP connection, it holds on to any IP options that came with that first packet. According to the kernel advisory, if a retransmitted copy of the same request arrives at the right moment, a second processor can still be reading those options after the new connection has already freed them [1]. The kernel ends up working with memory it no longer owns. The official CVE record spells out the attack. An unauthenticated peer sends a connection request carrying uncommon IP options (Record Route or Timestamp), retransmits it, and races the two code paths [2].

The kernel's CVE team scores it 9.8, critical, because it is reachable over the network, with low complexity and no privileges [2]. NVD had not published its own score when we checked [3]. Red Hat rates it critical too [6], while Amazon, which has already patched, scores it 8.1 because it considers the attack complex to pull off [22]. The advisory says IPv6 connections are not affected by the main issue [1].

The bug arrived in kernel 4.4. The CVE record lists these stable releases as fixed [2].

The MPTCP detail, and why LND users should care

Anthropic's exploit targets servers with a Multipath TCP listener, an extension that lets one connection run across several network paths at once [4]. It works in two stages. It first abuses the race to make the kernel echo back stray bytes of its own memory, until one of them leaks an address that reveals the kernel's layout. It then uses the same bug to redirect execution into a chain that ends with a root shell command [4].

Two numbers from that write-up pull in opposite directions. The proof of concept needed 48 minutes to leak its first kernel pointer and five more to reach command execution [4]. But a lost race only fails that one handshake and leaves the system running, so an attacker can retry indefinitely [4]. The post describes the technique and does not include exploit code. CIQ noted that CISA's Known Exploited Vulnerabilities catalog had no entry for the bug as of October 30 [15].

Here is where bitcoin comes in. On October 29 the Go security team warned that since Go 1.24, Go programs open their listening sockets as MPTCP by default on Linux [5]. LND is written in Go, and its developers confirm that 0.21.x exposed MPTCP listeners on the peer, gRPC and REST ports [13]. The Go team also stresses that the underlying bug is not specific to MPTCP and that systems without such listeners might fall to similar attacks [5]. Red Hat agrees that any system with a vulnerable kernel and IPv4 TCP is affected, with machines that accept inbound connections most exposed [6]. CIQ's own tests found that a plain TCP listener still processed the option-carrying packets with MPTCP switched off [15].

Bitcoin Core is written in C++, so the Go default does not apply to it. An open port 8333 is still a TCP door like any other.

Check your kernel

Run these on any Linux machine, from a terminal or over SSH.

uname -r
uname -v

The first line is the kernel version. On Debian and Raspberry Pi OS the second usually adds the exact package version, which is what you compare against your distribution's advisory. Debian users can also list installed kernel packages.

dpkg -l 'linux-image*' | grep ^ii

Be careful with Ubuntu and Red Hat. They number kernels their own way and backport fixes without changing the main version, so a 6.8.0 on Ubuntu or a 5.14.0 on RHEL tells you little against the upstream table. Their own trackers are the reference.

To see whether MPTCP is on and which programs listen with it, CIQ and LND suggest these two commands [13][15].

sysctl net.mptcp.enabled
sudo ss -Mltnp

A value of 1 means listeners can negotiate MPTCP, and the second command lists the ones that do. If the system says the key does not exist, your kernel has no MPTCP support and that particular path is closed [13].

Patch status as of October 31, 2026

Swipe the table →

Updating, platform by platform

Debian, Ubuntu and Raspberry Pi OS. The usual package upgrade, then a reboot. A new kernel does nothing until the machine boots into it.

sudo apt update
sudo apt full-upgrade
sudo reboot

Run uname -r and uname -v again afterwards to confirm the running kernel is the fixed one. On Ubuntu, the official pro client can check a specific CVE and apply the fix once it exists. No fixed package was out on October 31, so it is worth rerunning.

pro fix CVE-2026-98432

Red Hat, Rocky and AlmaLinux. Once a fixed kernel ships, CIQ's procedure is to update, reboot and confirm that the running kernel's changelog names the CVE [15].

sudo dnf update kernel*
sudo reboot
rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432

A result of 0 means the running kernel does not have the fix yet.

RaspiBlitz and myNode on a Raspberry Pi. Pis run kernels built by the Raspberry Pi project. The October 6, 2026 Raspberry Pi OS image ships 6.18.50 [23], and the first fixed 6.18 release is 6.18.56 [2]. We found no advisory about this CVE from RaspiBlitz or myNode as of October 31. Check your node distribution's documentation before upgrading system packages on your own.

Umbrel. umbrelOS updates come through the dashboard's settings, so the fix has to arrive as an umbrelOS release. As of October 31 there is none. An issue opened on October 30 in Umbrel's repository includes a user's report that their device runs kernel 6.12.96, older than the fix, with nothing newer offered by apt [16]. The Lightning Node app in Umbrel's store was still on LND 0.21.5-beta.rc1, which predates the MPTCP change [18].

Start9. Same story, the fix has to ship in a StartOS release. A user on the official forum reported on October 30 that StartOS 0.4.0.4 runs kernel 7.2.9, one release short of the fixed 7.2.10 [19][2]. The 0.4.1 release notes, published October 31, make no mention of the kernel or the CVE [20].

Stopgaps with official backing

None of these replaces the kernel update. They narrow the window until it arrives.

LND users, upgrade to 0.21.6 or 0.20.7. Both were released overnight from October 30 to 31 and turn off LND's MPTCP listeners by default [13]. The LND team also asks operators to switch MPTCP off for the whole host, because the new release does not cover other services on the machine.

sudo sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf

The first line applies the change at once, the second keeps it after a reboot. LND's notes point out that the setting is per network namespace, so on its own it does not reach an LND running inside Docker, as on Umbrel [13]. If you cannot upgrade LND yet, its developers say to start the existing binary with GODEBUG=multipathtcp=0 [13].

Filter IP options at the firewall. Red Hat's bulletin offers an nftables rule that drops incoming IPv4 TCP packets carrying IP options, the ingredient the attack needs. Red Hat expects ordinary traffic to be unaffected, since standard TCP options travel in the TCP header, but asks admins to test it first [6]. Save the following as cve-2026-98432.nft.

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Then validate and load it [6].

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Once the kernel is patched, one command removes it [6].

sudo nft delete table inet cve_2026_98432

That rule filters traffic addressed to the host itself. For ports published by Docker containers, LND's notes point to a rule earlier in the packet path that, according to the team, covers every network namespace [13][14].

sudo iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -m comment --comment CVE-2026-98432 -j DROP

It does not survive a reboot. On Umbrel and Start9, changing the host firewall or kernel settings over SSH takes you outside what those systems manage for you, so only do it if you are comfortable there. The simpler move is to close the router port forwards to your node and run Tor-only until the OS update lands.

What an attacker could reach

Root on the node's machine means access to everything stored on it. That includes LND's wallet, with your channel balances and on-chain funds, any wallet loaded in Bitcoin Core, and the credentials other apps use to move those funds. In short, whatever the node keeps hot.

Keys that never touch the machine stay out of reach. A seed that lives only on a hardware wallet and on paper never passes through the node, as we noted in our DarkSword coverage, and the blockchain itself is untouched. What patching protects is the access to the node's hot funds.

No specific indicators of compromise have been published. If your node faced the internet on an unpatched kernel and holds funds you care about, the cautious step, once it is patched, is to move those funds to a new wallet created on a different device.

A busy week for node security

Details of two bugs found with the help of language models reached node operators within two days. On October 28, 2026 Bitcoin Core published three security advisories, one of them about TCP urgent data that could crash nodes on Windows, macOS or BSD but not on Linux, as covered in our Bitcoin Core 32.1 checklist. This time the problem sits one layer down, in Linux itself, under every program that listens on the network.

There is a reassuring side. Anthropic reported the bug to the kernel developers before describing it, and by the time the write-up went out the fix had been backported to every maintained stable branch [4]. Debian shipped packages the day after the CVE went public [9]. For a home node, the work fits into an afternoon. Check the kernel, apply whichever stopgaps fit your setup, and watch for your system's update. For a case where updating the wallet app was the whole fix, see our Electrum 4.8.3 piece.

Sources

Source type in brackets.

1. Linux kernel CVE team, CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period, linux-cve-announce, October 15, 2026. (Primary, official kernel advisory)
2. CVE Program, CVE-2026-98432 record, updated October 30, 2026. Fixed versions, 9.8 score and attack scenario. (Primary, official record)
3. NIST, CVE-2026-98432 in the NVD, accessed October 31, 2026. (Primary, official database)
4. Anthropic Frontier Red Team, Discovering and exploiting vulnerabilities in critical, real-world software with Claude, October 27, 2026. (Primary, finder's write-up)
5. Go security team, Protecting against CVE-2026-98432, forwarded to oss-security, October 29, 2026. (Primary, official language advisory)
6. Red Hat, RHSB-2026-016 Use-after-free - kernel IPv4 (CVE-2026-98432), October 30, 2026. Severity, scope and nftables rule. (Primary, official bulletin)
7. Red Hat, CVE-2026-98432 page, accessed October 31, 2026. Affected products. (Primary, official record)
8. Debian, security tracker, CVE-2026-98432, accessed October 31, 2026. (Primary, official record)
9. Debian, DSA-6568-1 linux security update, October 16, 2026. (Primary, official advisory)
10. Debian LTS, DLA-4841-1 linux security update, October 17, 2026. (Primary, official advisory)
11. Debian LTS, DLA-4850-1 linux-6.12 security update, October 22, 2026. (Primary, official advisory)
12. Canonical, Ubuntu, CVE-2026-98432, updated October 30 and accessed October 31, 2026. (Primary, official record)
13. LND, 0.21.6 release notes and 0.20.7 release, October 30-31, 2026. (Primary, official repository)
14. LND, issue #11455, Disable MPTCP on listeners by default, October 30, 2026. Firewall rule covering all namespaces. (Primary, official repository)
15. CIQ, Mitigating CVE-2026-98432 on Rocky Linux 8, 9, 10, and LTS Variants, October 30, 2026. (Primary, vendor knowledge base)
16. Umbrel, issue #2292, CVE-2026-98432, opened October 30, 2026. (Primary, official repository, user reports)
17. Umbrel, umbrelOS releases, accessed October 31, 2026. (Primary, official repository)
18. Umbrel, Lightning Node app manifest, accessed October 31, 2026. (Primary, official repository)
19. Start9 community, MPTCP exploit (CVE-2026-98432), October 30, 2026. (Secondary, official forum, user reports)
20. Start9, StartOS 0.4.1 release notes, October 31, 2026. (Primary, official repository)
21. PaulsCode, Linux kernel bug CVE-2026-98432 and your Lightning node, October 30, 2026. (Secondary, community developer's forum)
22. Amazon Linux, CVE-2026-98432, updated October 30, 2026. (Primary, official record)
23. Raspberry Pi, Raspberry Pi OS release notes, October 6, 2026 image. (Primary, official notes)

More in Privacy and self-custody

News

Chainalysis Breach Exposed the Names, Emails and Roles of People Who Use Its Tools

News

Trezor Warns CryptoBilis Buyers Before Its Lab Has Seen the Reported Implant

News

Coinbase Says a Breach at Analytics Vendor Amplitude Exposed Some Customers' Contact Data

See all 30 articles in Privacy and self-custody →

Last updated: October 31, 2026