CVE-2026-98432: what the Linux TCP flaw means for your servers, and what to do now

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake code. Anyone who can send packets to a listening IPv4 TCP port can reach it, with no login and no user interaction. The kernel CVE team scores it 9.8 out of 10.

The bug has been in the kernel since Linux 4.4, released in January 2016. Most of the time, a flaw like this needs a module, a niche protocol or an unusual configuration. This one sits in the code that accepts ordinary IPv4 connections, and that code runs before your application sees a single byte.

On 27 October, Anthropic said an unreleased AI research model had written a working remote root exploit for it. As of 2 November, no vendor or CERT reports exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog. That is the window to act in, and for some distributions the fix is still not out.

The short version:

• What: a race condition that makes the kernel use memory it has already freed, while it answers a TCP connection request.
• Who: Linux 4.4 and later, on any host that accepts IPv4 TCP connections from an untrusted network, until the fix is installed and running.
• Not affected: Red Hat lists RHEL 7 as not affected, and the main bug does not apply to IPv6.
• Fix: a fixed kernel plus a reboot, or a livepatch that covers this CVE. Installing the package alone changes nothing.
• Stopgap: an nftables rule that drops inbound TCP packets with IPv4 options. It reduces exposure, and Red Hat states it cannot fully prevent exploitation.

The second half of this article looks at why this keeps happening. AI models are finding serious flaws faster than most organisations can patch them, and that changes how you should think about any platform that holds something valuable on your behalf.

How the bug works

The flaw is a lifetime error: one CPU frees a small object while another CPU is still reading it. It needs a TCP connection that carries IPv4 options, which normal traffic almost never uses, but which any client can send.

The path through the handshake

When a SYN arrives with IPv4 options, such as Record Route or Timestamp, the kernel saves them with the pending request in ireq->ireq_opt. It needs them to echo the options in the SYN-ACK.

When the handshake completes, tcp_v4_syn_recv_sock() hands those options to the new child socket as newinet->inet_opt. It transfers ownership and does not make a copy. Request socket and child now point at the same memory.

That is safe only if nobody else is using the request socket. Since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), request sockets are processed without holding the listener lock. So a second CPU can pick up a retransmitted SYN for the same request and build another SYN-ACK at the same moment.

Client                  CPU 0                          CPU 1
------                  -----                          -----
SYN + IPv4 options  --> request socket created,
                        options saved in ireq_opt
SYN (retransmit)    ---------------------------------> tcp_check_req()
                                                       tcp_v4_send_synack()
                                                       reads ireq_opt under
                                                       rcu_read_lock()
ACK                 --> tcp_v4_syn_recv_sock()
                        moves ireq_opt to the child
                        socket, no copy
Connection closed   --> child socket torn down
                        inet_sock_destruct()
                        kfree(inet_opt)
                                                       ip_options_build()
                                                       reads freed memory

Why RCU did not protect it

The readers do the right thing. tcp_v4_send_synack() and inet_csk_route_req() read the options under rcu_read_lock().

RCU is a contract with two sides, though. A reader may keep using an object until it leaves its critical section, on the condition that the writer waits for a grace period before freeing. inet_sock_destruct() broke that contract with a plain kfree(), because TCP child sockets do not have SOCK_RCU_FREE.

Other paths that replace inet_opt, such as do_ip_setsockopt() and cipso_v4_sock_setattr(), already used kfree_rcu(). This was the one place that was missed, and it stayed missed for almost eleven years.

What a won race can do

The readers use opt->optlen twice, in ip_build_and_send_pkt() and in ip_options_build(). If the freed object has been reused for something else, both work with stale or attacker-influenced values. The CVE record lists three outcomes:

• Information leak: ip_options_build() copies opt->__data for the stale length into the outgoing SYN-ACK, which can send adjacent kernel heap memory to the peer.
• Memory corruption: stale lengths and stale srr, rr or ts offsets steer copies and writes out of bounds, with potential control-flow corruption.
• Crash: a reclaimed optlen can make skb_push() run past the SYN-ACK headroom and call skb_under_panic().

The second path: request socket migration

A related race exists when request sockets migrate between listeners. It needs net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program, and the sysctl is off by default.

Here reqsk_timer_handler() clones the request with inet_reqsk_clone(), so old and new share one ireq_opt. reqsk_migrate_reset() then clears the pointer in the old one, while another CPU may still hold a reference and be using the options. tcp_v4_reqsk_destructor() also used a plain kfree().

Why IPv6 escapes the main bug

tcp_v6_syn_recv_sock() duplicates the options, so the first race does not exist there. tcp_v6_reqsk_destructor() has the same migration issue, but only for ipv6_opt set by CALIPSO. The kernel team addresses that in a separate patch.

The fix

The upstream fix, written by Eric Dumazet, changes kfree() to kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(). Anything still reading the options finishes before the memory is released. It is a tiny change for a bug that scores 9.8.

The fix is in upstream 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Do not compare those numbers with uname -r on a distribution kernel. Distributions backport fixes, so a version number says little. Check your vendor's advisory.

Why vendors disagreed on the score

The vendors agree on nearly every metric. The spread came from attack complexity: is a race like this easy or hard to win?

The kernel team's reasoning is that the attacker controls both sides of the race: the SYN, the retransmission and the teardown. The counterargument is that winning a race takes many attempts. That argument lost much of its weight once it became clear that a lost race costs the attacker almost nothing.

There is a practical lesson here. Red Hat first rated this flaw Moderate. If your patch SLA follows the vendor rating, this bug may have looked routine for most of October.

The exploit: what is claimed, and what is not known

Anthropic says an unreleased, internal Claude research model wrote a remote root exploit for this bug. The claim comes from one vendor and has not been publicly reproduced, so treat it as credible but unverified.

Anthropic's post of 27 October, from its Frontier Red Team, describes a remote attacker with no credentials running commands as root on Linux servers with a multipath TCP listener. Anthropic researcher Xinyang Ge is credited as the reporter in the fix.

The post describes two stages:

1. Defeat KASLR. The attacker uses the race to make the kernel read a controlled length field and copy extra bytes into its reply. One reply containing a kernel pointer reveals the kernel's address layout.
2. Hijack control flow. The same bug overflows a buffer and overwrites a callback pointer. When the kernel calls it, a payload staged earlier in kernel memory runs an attacker-chosen shell command as root.

In the proof of concept, the leak took 48 minutes and command execution took another five. That is a measured run on an undisclosed test system, so it does not predict how long an attack takes on your server.

The detail that matters most for defenders is this one: a lost race fails only that handshake and does not crash the machine. An attacker can keep retrying, and a noisy crash log may never appear. A quiet log is therefore no evidence of safety.

What we do not know

• Anthropic did not publish the exploit code, the kernel version or the tested configuration.
• TuxCare found no independent public reproduction as of 30 October.
• Neither the CVE record nor the fix mentions multipath TCP. That link comes only from Anthropic's post.
• Nobody has publicly shown remote root on a server without an MPTCP listener. The Go Security Team warns that such systems may still be vulnerable to similar attacks.

Why MPTCP matters, and why it is not the whole story

Multipath TCP lets one connection use several network paths at once. On Linux, an application has to ask for it when it opens a socket, so for years most teams could assume they were not running it.

Go changed that assumption. Since Go 1.24, Go programs enable MPTCP on listening sockets by default on Linux. A reverse proxy, API gateway or internal service written in Go may therefore hold an MPTCP listener that nobody asked for.

Whether that listener really exists depends on the distribution:

• RHEL, Rocky Linux and AlmaLinux ship with net.mptcp.enabled=0, so a Go service falls back to plain TCP unless someone switched MPTCP on.
• Other distributions may keep the upstream default of 1. Check rather than assume.

Disabling MPTCP removes the setup Anthropic demonstrated. It does not remove the bug, which sits in regular IPv4 TCP code. A host with MPTCP off is less exposed, and it still needs the patch.

Patch status per distribution, as of 2 November

The upstream fix has been in stable kernels since mid-October, but what counts is the kernel your distribution ships. Ubuntu had still not released a fixed kernel on 2 November. AlmaLinux moved its fixed kernels into the regular repositories that day; Rocky Linux offered interim kernels while regular advisories were pending. This changes daily, so check the linked tracker before you act.

The gap between upstream and vendor is the real exposure. Debian had a fixed kernel on 16 October. Red Hat followed about two weeks later and AlmaLinux released its regular updates on 2 November. Ubuntu had not shipped at all, while a public write-up already described how a working chain fits together.

End-of-life kernels are a separate problem. Branches between 4.4 and 5.4 are no longer maintained upstream, so they get no upstream fix.

What to do now

Install a fixed kernel and boot into it. Everything else in this section buys time or reduces exposure, and none of it replaces the patch.

1. Inventory every kernel you actually run

Start with hosts that accept IPv4 TCP from untrusted networks, then work inwards. Count kernels, not servers:

• Bare metal and hypervisors each run their own kernel.
• Virtual machines each run their own kernel too. A patched Proxmox host does nothing for an unpatched guest, and the reverse is also true.
• Containers share the host kernel. Rebuilding an image fixes nothing here.
• Appliances and vendor kernels inherit the vendor's schedule. Ask them.

2. Install the fix and reboot

# RHEL, Rocky Linux, AlmaLinux, Oracle Linux
sudo dnf update 'kernel*'
sudo needs-restarting -r
sudo reboot

# Debian, Proxmox VE
sudo apt update && sudo apt full-upgrade
sudo reboot

Plan the reboot deliberately. On a cluster, migrate guests away and patch nodes one at a time, so a kernel update does not become an outage.

A livepatch only counts if your vendor explicitly lists this CVE for your exact kernel. For Ubuntu, Livepatch has nothing to apply until a fixed kernel exists. Prepare the update and the reboot window now, so you can move on the day it ships.

3. Verify the running kernel, not the installed package

A fixed package on disk protects nothing until the system runs it.

# Which kernel is running right now?
uname -r

# RPM-based: does the running kernel's changelog mention this CVE?
rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-98432

# Proxmox VE: 7.0.14-25-pve or newer has the fix
uname -r

Compare the result with your vendor's advisory. A changelog hit is not proof on its own, and upstream version numbers do not apply to backported kernels.

4. No fix yet? Drop inbound TCP packets with IPv4 options

The documented trigger needs a TCP SYN carrying IPv4 options. Those packets have an IP header longer than the standard 20 bytes, so ip hdrlength > 5 matches them. Normal traffic almost never uses IPv4 options.

AlmaLinux published this rule and tested it on AlmaLinux 8, 9 and 10:

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF

# Check it is active, and see how many packets it dropped
sudo nft list table ip cve_2026_98432

Red Hat recommends the same match on the input hook, at priority -310. The input hook only sees traffic for the host itself, while prerouting also sees traffic on its way to containers. Red Hat states that filtering cannot fully prevent exploitation and is no substitute for patching.

Before you rely on it, keep these limits in mind:

• It does not survive a reboot. Load it again, or add it to your persistent firewall configuration.
• It covers the host and its port-forwarded containers. Traffic between containers on the same host may bypass it.
• Routers and firewalls need care. Forwarded TCP packets with IPv4 options get dropped as well.
• Do not use it if you rely on CIPSO or NetLabel. Those labels travel in IPv4 options, and in that setup the kernel adds them itself, so the rule would not cover it anyway.
• Add it inside each exposed guest. Do not assume a rule on the hypervisor protects the virtual machines behind it.
• Test it first. CIQ notes that fragmented packets and other paths have not been tested.

If you can filter at the network edge, that covers every host behind it, as long as all traffic really passes through that edge.

5. Find and remove MPTCP listeners you do not need

# 1 means applications can open MPTCP sockets
sysctl net.mptcp.enabled

# Every line printed is an MPTCP listener
sudo ss -H -lMnp

If nothing needs MPTCP, turn it off and keep it off:

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

This only stops new MPTCP sockets, so restart the services that own existing listeners. For Go programs, the Go Security Team gives two per-program switches: GODEBUG=multipathtcp=0 at runtime, or godebug multipathtcp=0 in the main module's go.mod. It calls this approach fragile, because one forgotten listener leaves the system exposed. The system-wide sysctl is the better choice.

6. Close the migration path

# Should print 0, the default
sysctl net.ipv4.tcp_migrate_req

Also confirm that no BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is loaded, unless you rely on one.

7. Watch for signs of trouble

No vendor or CERT has published indicators of compromise. The most useful signal is a kernel oops on an internet-facing host:

sudo journalctl -k | grep -E 'ip_options_build|ip_build_and_send_pkt|skb_under_panic'

A clean result proves little, because a lost race does not crash the server. The packet counter on the nftables rule is worth watching too: a sudden burst of TCP packets with IPv4 options from one source deserves a look.

8. Ask your suppliers

Your SaaS vendors and hosting providers run Linux too, so you inherit their patch speed. Four questions, in writing, are enough:

1. Which distributions and kernel versions run your internet-facing services?
2. Is a fixed kernel installed and running after a reboot, and since when?
3. Do any of those services expose MPTCP listeners?
4. If no fix is available yet, which interim controls are in place, and how fast will you deploy once it ships?

Why this keeps happening: AI changed the economics of finding bugs

CVE-2026-98432 is no isolated case. AI models now find serious flaws in mature software at a pace maintainers and patch teams struggle to absorb, and the time between a fix and an attack keeps shrinking.

A bug that survived almost eleven years of human review was found by a researcher working with an AI model. Anthropic's post lists exploit chains for Chrome, Safari, Android and Windows next to this one. Those are among the most heavily audited codebases in the world, which is the point: if these are not safe from this kind of search, the average business application is not either.

What the numbers show

• Volume in Linux: stable maintainer Greg Kroah-Hartman reports about 500 CVEs per release in the 6.x era, more than 1,000 for Linux 7.0 and more than 1,500 for Linux 7.2.
• Pressure on maintainers: networking maintainer Jakub Kicinski wrote "We are completely overwhelmed" in his pull request for Linux 7.3.
• Volume everywhere: Google's threat intelligence group counted 5,045 published CVEs in January 2026 and 10,740 in August.
• Severity: 50% of the flaws Google attributes to AI discovery lead to remote code execution, against 26% of the rest.
• Exploitation: Google saw 141 exploited vulnerabilities in the first eight months of 2026, against 127 in all of 2025.
• Attackers using AI: in May, Google reported the first zero-day exploit it believes was developed with AI.
• Speed: Mandiant's M-Trends 2026 estimates a mean time to exploit of minus seven days, meaning exploitation on average begins before a patch exists. In 2018 that window was 63 days.

Two cautions keep this honest. The raw CVE count overstates the danger, because only 0.23% of this year's published CVEs were seen exploited, and the kernel team assigns CVEs very broadly. The AI link in the exploitation numbers is also partly inference: Google suspects attackers use AI, and it labels its attribution of AI discoveries a heuristic.

The real shift is the patch itself

Google's most useful finding for defenders concerns n-days, flaws that already have a fix. It believes those drive most of the growth, and suspects attackers use AI to turn patches and advisories into exploits quickly.

That changes what a patch is. A published fix used to be the end of the story. Today it is also a signpost, showing attackers exactly where to look. CVE-2026-98432 is a good example: Anthropic published no exploit code, yet the fix, the CVE record and the write-up together describe the shape of the attack in public.

The same technology helps defenders, and this case shows that too. The bug was found, reported and fixed before anyone reported an attack. The advantage goes to whoever acts first, so the question is how fast your side moves.

What this means for how you run infrastructure

• Patch in days, not in monthly cycles. For internet-facing systems and a flaw like this one, a four-week window is no longer defensible.
• Make reboots boring. If rebooting a node is a project, you will postpone it. Build for rolling restarts, so a kernel update is routine.
• Do not wait for the label. This flaw went from Moderate to Critical at Red Hat in weeks. Use reachability from the internet as your first filter, not the vendor's rating.
• Shrink what is exposed. Every open port and forgotten service is code an attacker can reach, as the unwanted MPTCP listeners show.
• Assume something will get through. Segment networks, test your backups by restoring them, and limit what one compromised host can reach.
• Know your supply chain. Your risk includes the patch speed of every provider below you.

For the wider operating practice, read our guides to reducing a server's attack surface and finding gaps in infrastructure monitoring.

At Binadit we treat this as the new normal. We watch advisories for the kernels and software we run, and we install every available update as soon as it is released. If you would rather not carry this yourself, talk to one of our engineers.

What this means if you hold crypto on a platform

If AI makes flaws cheaper to find and faster to exploit, the most attractive targets feel it first. A crypto platform that holds the keys for millions of customers is such a target, so it makes sense to keep only what you actively trade there and move the rest to a wallet you control yourself.

That is a trade-off, and you take on real risks of your own. This section sets out both sides. It is general information, not financial advice.

Platforms are concentrated targets

On 29 October, TRM Labs reports, about USD 6.36 billion left Binance wallets across ten blockchains, most of it within roughly 20 minutes. It is the largest crypto theft on record, about four times the Bybit hack of February 2025.

TRM attributes the attack to TraderTraitor, a North Korean unit, with high confidence. It suspects a compromise of Binance's hot wallet signing infrastructure, but Binance has not published a root cause. Nothing links this theft to CVE-2026-98432, and no source says AI was used. It is relevant here for a different reason: it shows what one compromised signing system can do at a platform.

The wider figures point in the same direction, with one caveat:

• More incidents: TRM counted 207 hacks in the first half of 2026, against 83 a year earlier.
• But smaller, until Binance: losses in that half fell to about USD 972 million, from about USD 2.3 billion.
• The whole year so far: DefiLlama lists 322 hacks and USD 8.73 billion up to 30 October, with Binance making up about 73% of that amount.
• Keys and infrastructure do the damage: in TRM's first-half data they caused about 15% of incidents and about 76% of losses.

That last line matters most. Big losses rarely come from an exotic smart contract bug. They come from the same places this article is about: servers, signing systems, access rights and the software underneath.

Is the risk really going up?

We think so, but nobody can measure it precisely. No public data separates AI-driven platform hacks from the rest. Our reasoning is an inference from three facts:

1. Platforms run on the same operating systems, libraries and supply chains that AI models are now searching.
2. Attackers appear to be turning published fixes into exploits faster.
3. A platform only has to lose once, and pooled customer assets make that one success enormously valuable.

What a platform balance actually is

When your crypto sits on a platform, the platform controls the keys. What you hold is a claim on that company, and that has practical consequences:

• Access can stop. Binance paused withdrawals during the incident and reopened them on 1 November, first for 15 networks and assets. Customers then pulled out a net USD 3.64 billion in the first 9.5 hours.
• Compensation depends on the company. Binance says it will cover all losses from its SAFU fund and company funds, and that users will not bear the cost. A smaller platform may not be able to promise that.
• There is no state guarantee. Under MiCA article 6(5), a crypto-asset white paper must state that the asset is not covered by investor compensation or deposit guarantee schemes.

European rules do help. Under MiCA article 75(7), a licensed custodian must keep client assets legally and operationally separate from its own estate, so its creditors cannot claim them in an insolvency. Under article 75(8) it is liable for losses from incidents attributable to it, up to the market value at the time of loss. That protection is only as good as the provider's ability to pay, and it applies to providers that actually fall under MiCA.

Platform or own wallet?

Your own wallet is no free pass

Self-custody moves the risk to you. Chainalysis figures put thefts from personal wallets at about USD 713 million in 2025, roughly 20% of all stolen crypto. In December 2025, a malicious update of the Trust Wallet Chrome extension drained about USD 7 million from hundreds of accounts. TRM also records a physical "wrench attack" of USD 24 million in the first half of 2026.

If you do move your crypto, these habits cover most of the risk:

• Use a hardware wallet for long-term holdings. Buy it directly from the manufacturer, never second-hand. Keep keys away from browser extensions and always-online devices.
• Protect the seed phrase offline. Write it on paper or metal and store it securely. Never photograph it, type it into a website or keep it in the cloud. Nobody legitimate ever asks for it.
• Test before you move everything. Send a small amount first, and check the network and address. Practise a restore while the amount is still small.
• Read what you sign. Check the transaction on the device's own screen, and refuse to sign anything you cannot read. Blind signing is how drainers empty wallets.
• Split by purpose. Keep a trading balance on a regulated platform, a small hot wallet for daily use, and the rest in cold storage.
• Stay quiet about what you own. Public bragging is how a small target becomes a big one.
• Plan for your absence. If only you can reach the seed phrase, your family cannot either.

Self-custody is not for everyone. If you hold a small amount, or you doubt you can keep a seed phrase safe for years, a well-regulated platform may well be the smaller risk. What matters is making that choice deliberately, rather than leaving everything on a platform by default.

The same logic applies well beyond crypto: know who holds the keys to what matters to you, and what happens on the day that party is breached.

Sources

Checked on 2 November 2026. Vendor links in the patch table that are not listed here were taken from Rescana's and TuxCare's overviews.

The vulnerability

• CVE record, CVE-2026-98432
• Ubuntu: CVE-2026-98432
• Red Hat: CVE-2026-98432
• Red Hat: security bulletin RHSB-2026-016
• AlmaLinux: patched kernels in regular repositories
• CIQ: mitigating CVE-2026-98432 on Rocky Linux
• Rocky Linux forum: any roadmap?
• Proxmox forum: CVE-2026-98432 in Proxmox VE
• Go Security Team via oss-security
• Rescana: critical TCP use-after-free
• TuxCare: root exploit and patch status

AI and vulnerability trends

• Anthropic: discovering and exploiting vulnerabilities with Claude
• Help Net Security on Google's AI vulnerability report
• Google Threat Intelligence Group: AI Threat Tracker
• Tom's Hardware: Linux kernel nears 2,000 CVEs per release
• Security Boulevard: mean time to exploit has gone negative

Crypto

• TRM Labs: the Binance theft
• TRM Labs: H1 2026 crypto hacks
• FinanceFeeds: 322 incidents, USD 8.73 billion
• ABC7: Binance estimates impact at USD 6.3 billion
• Techloy: net outflows after the hack
• CryptoSlate: losses from personal wallets
• Regulation (EU) 2023/1114 (MiCA), articles 6, 70 and 75