Anza tells Solana validators on Ubuntu to act on the Linux flaw Intersect flagged for Cardano, as Red Hat ships fixes

Update, 2 November 2026, 05:55 UTC: Anza, which develops the Agave validator client for Solana, has told validators running Ubuntu to filter inbound traffic and disable two networking features until a fixed kernel ships, The Defiant and TokenPost reported on the evening of 1 November, US time. Red Hat issued fixed kernels for RHEL 8, 9 and 10 on 1 November, according to its advisories. Ubuntu’s tracker, last updated on 30 October, still showed no fix when we read it on 2 November. Nothing we read gives a deadline or the share of Solana stake concerned.

Cardano stake blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool operators were told on 30 October by Intersect, the network’s member organisation, to check the Linux kernel on their block producers and relays, then install a fixed kernel and reboot as soon as their distribution publishes one. The flaw, CVE-2026-98432, carries a CVSS score of 9.8 out of 10. It is a bug in the Linux kernel, not in Cardano, and Intersect’s weekly update says nothing about funds, consensus or exploitation.

Operators on Ubuntu still cannot follow that advice. When we read its tracker on 2 November, last updated on 30 October, all seven releases it lists from 16.04 to 26.10 were marked vulnerable. Red Hat, which listed no fixed kernel on 31 October, has since published fixes for RHEL 8, 9 and 10. No exploitation in the wild is reported in the sources we read, and the flaw was absent from the CISA Known Exploited Vulnerabilities catalog (still version 2026.10.30) when we checked on 2 November. That is a statement about those sources, not proof that no attack exists.

Anza tells Solana validators on Ubuntu to act on the same flaw

Solana is the second network whose operators we know have been warned. The Defiant reported at 00:23 UTC on 2 November that Anza told Ubuntu operators to filter incoming traffic and disable two networking features while they wait for a fixed kernel. TokenPost carried the same alert at 19:26 US Eastern time on 1 November, or 00:26 UTC on 2 November. We found no public copy of Anza’s notice, so this rests on those reports.

The steps themselves were relayed by Tim Garcia, who leads validator relations at the Solana Foundation. According to TokenPost, he said the kernel flaw has been fixed but Ubuntu has released no patch, and until it does validators should block inbound TCP packets containing IPv4 options, disable Multipath TCP and disable TCP request socket migration. The advice is temporary and covers validators on Ubuntu, not every Solana validator. The third step has a basis in the CVE text, which describes a similar problem with request socket migration when the setting net.ipv4.tcp_migrate_req is 1.

Ubuntu matters here because of what Anza documents: its requirements page says “We build and run on Ubuntu 24.04” and that a public IPv4 address is required. The Defiant’s article, as carried by cryptonews.net, dates the warning 1 November and says taking over a host could expose the validator identity key kept on it, while a kernel crash could interrupt block production. Anza’s security page limits another risk in advance: “the withdrawer keypair should never be stored on your validator at any time.”

Several things are not known. No source we read gives a deadline, the share of Solana stake running on Ubuntu, or how much of it has applied the steps. None says a validator was hit, or whether validator software opens an MPTCP listener, the condition of the published proof of concept. We also could not establish whether operators of other Solana clients received separate guidance.

Pushback came the same night. TokenPost reported that 23pds, chief information security officer at SlowMist, disputed claims that every Ubuntu system has a zero-click path to root. By that account, exploitation needs a server listening for MPTCP, which Linux does not enable by default, and he had seen no official confirmation of large-scale exploitation. That sits awkwardly with the warning from Go’s Damien Neil, below, that the root cause is not MPTCP-specific.

What Intersect told Cardano stake pool operators

The notice is a few lines headed “Security advisory for SPOs”, inside the section on Cardano upgrades of weekly update #135. We found no stand-alone post. It says fixed kernels exist for some distributions while others, Ubuntu included, are still preparing theirs, and it links to Ubuntu’s page on the flaw.

“If you run a stake pool, check which kernel your block producer and relays use,” Intersect wrote. Operators are then told to apply the fixed kernel and reboot. More guidance is promised on X and in SPO channels. The notice gives no technical detail and prescribes no workaround.

Do not confuse this with the Node 11.2 pre-release in the same update. That release carries the Dijkstra hard fork features minus Leios, the scaling work whose code merge we covered this week. A cardano-node upgrade changes the node software, not the operating system kernel, so it does nothing for this flaw.

CVE-2026-98432 is a race in the Linux TCP code

According to Ubuntu’s description, the bug sits in the kernel’s IPv4 TCP handling. When a connection is being set up, the memory holding its IP options can be freed while another processor core is still reading it to build a reply to a retransmitted connection request. Reading memory after it has been freed is called a use-after-free. The fix delays the release of that memory until no reader can still be using it.

Red Hat’s bulletin RHSB-2026-016, dated 30 October, says a remote, unauthenticated attacker could exploit the race, potentially reaching remote code execution. It adds: “Exploitation requires precise timing of network requests but does not require any privileges or user interaction.” Any system with a vulnerable kernel and IPv4 TCP networking enabled is affected, Red Hat says, and machines that accept inbound TCP connections most directly. The CVE record gives 4.4 as the first affected kernel, and lists the upstream fixes in stable versions 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10.

Two dates: the CVE on 15 October, the exploit write-up on 27 October

Ubuntu and the US National Vulnerability Database both give 15 October as the publication date of the CVE. Ubuntu’s page was last updated on 30 October, NVD’s record on 31 October. Anthropic’s research post, which describes an exploit for the flaw, is dated 27 October. That date belongs to the post: the page gives none for the CVE itself. Intersect’s notice came three days later.

Fixes reached the upstream stable kernel lines, yet Red Hat customers waited until 1 November, 17 days after the CVE record appeared, and Ubuntu customers were still waiting on 2 November. Red Hat’s advisories say a reboot is required. Its bulletin, still dated 30 October when we reread it, keeps saying fixes are being expedited; the CVE data and the advisories are the later word. Status by distribution, as read on 2 November:

An MPTCP maintainer questions the 9.8 score

Anthropic’s post says its AI model Claude, after initial prompting, wrote an exploit that lets a remote attacker run commands as root, with no credentials, on Linux servers with a multipath TCP (MPTCP) listener. Its proof of concept took 48 minutes to leak a kernel pointer and five more to run a command. A lost race only fails the handshake, the post says, so an attacker can keep trying.

Matthieu Baerts questioned that picture on 30 October in a Go issue tracker thread. The Linux kernel’s MAINTAINERS file lists him as a maintainer of the MPTCP code, though he stated no role in his comment. He wrote that the reproducer ran in a lab, sent a huge number of connection requests and used MPTCP because, by luck, that took less time than TCP. He added that he is “pretty sure” IPv4 options are already blocked on many networks, and that the attack seems very unlikely to work outside a lab. “I have no idea how they got a 9.8 score in some places,” he wrote, calling the post an “ad”.

The day before, Damien Neil, answering for the Go project in the same thread, had been more cautious. He wrote on 29 October that the root cause “is not MPTCP-specific”. As far as he could tell, nobody knew whether code execution was possible without an MPTCP listener, and he advised against hoping it was not. The Go security team’s advisory of the same date calls a patched kernel the best fix.

The official ratings do not settle it. Red Hat calls the flaw Critical and so rates its RHEL 8 advisory, though the RHEL 9 advisory, which bundles 18 CVEs, and the RHEL 10 advisory carry an overall rating of Important. On 31 October its CVE page called the CVSS figures preliminary; that wording was gone on 2 November. The page still says reliable code execution requires precise heap control, and that the flaw primarily results in a crash or potential memory corruption. Ubuntu shows 9.8 with a priority of High. The NVD record still carried the status “Received” on 2 November, meaning NVD has not analysed it yet.

What is not known about Cardano nodes

None of the sources we read says whether a cardano-node host can be attacked through this flaw, or whether that software opens an MPTCP listener, the condition of the published proof of concept. In general, relays accept inbound TCP connections from the network, and Red Hat names such machines as the most directly exposed. That is our own reading of how relays work, not a finding about Cardano from any source.

Intersect’s notice does not mention funds or consensus, and no source we read links the flaw to either. This is a flaw in server operating systems, not in the Cardano protocol. Delegating does not hand ADA to a pool: “Your ada stays in your wallet and remains spendable at any time,” cardano.org says.

We found no separate statement from the Cardano Foundation or Input Output on 31 October. Anza’s is the only notice from another chain we have found, although Red Hat’s description covers any Linux system with a vulnerable kernel and IPv4 TCP enabled.

What Cardano and Solana operators can do now

The steps below come from Intersect and the vendors. Neither Intersect’s notice nor the reports of Anza’s give any instruction to people who delegate their staking. We could not read Anza’s own notice, so we print no command lines for its steps: Ubuntu validators should take those from the notice itself.

1. Check which kernel the block producer and each relay run, as Intersect asks.
2. Compare it with your distribution’s security page, because the fixed version differs by release.
3. Install the fixed kernel once it is published, then reboot. Intersect names the reboot explicitly, and Red Hat’s advisories say the system must be rebooted for the update to take effect.
4. AlmaLinux users can help test the kernels in the testing repository, which the project asks people to verify before production use.
5. Red Hat’s bulletin gives an interim nftables rule that drops incoming IPv4 TCP packets carrying IP options. It says the rule reduces exposure but cannot fully prevent the flaw, and that it may disrupt workloads, so test it first.
6. For AlmaLinux users only, not an instruction from Anza: AlmaLinux’s post of 30 October says that if MPTCP is on and not needed, run sudo sysctl -w net.mptcp.enabled=0. This only stops new MPTCP sockets, it says, so list open listeners with sudo ss -lnMp and restart the services that own them.

Red Hat is plain about the limits of its filter: “Applying kernel security updates as they become available is the only complete solution.”

Next to watch: the fixed Ubuntu kernels, Red Hat’s remaining products, NVD’s analysis of the score, any change to the CISA catalog, the further guidance Intersect has promised, and any public text from Anza.