Security notice

A Linux kernel flaw can be reached over the network with no login. Update your server's kernel and reboot.

Last updated: Wednesday, November 4, 2026, 5:10 PM ETStatus: Fixes out; Ubuntu's in testing. No confirmed attacks, suspected scanning. Update and reboot.

The Linux kernel is the core of the operating system that most web servers run. On October 15, 2026, the Linux kernel team published CVE-2026-98432, a flaw in how the kernel starts network connections. In the kernel team's own record, someone with no login can reach it over the network, and it is rated up to 9.8 out of 10 (some vendors rate it 8.1 to 8.3). Fixed kernels are out for Debian, Oracle Linux, Amazon Linux, Rocky Linux, Red Hat Enterprise Linux and AlmaLinux. Ubuntu's fixes for 22.04, 24.04 and 26.04 are in its "-proposed" testing area, which you have to switch on yourself, and its older releases are still waiting. Anthropic says its AI model built an exploit, in its own tests, that gives remote root control, meaning full control of the server, against servers running one specific network feature, multipath TCP. We found no confirmed attacks, Amazon says it is not aware of any in the wild, and CISA does not list the flaw as exploited. But security researcher Marcus Hutchins said on November 2 that he saw internet-wide scanning that he strongly suspects is looking for this flaw, and that his own scan found about 2.1 million servers reachable over multipath TCP on port 443. That counts exposure, not unpatched servers. Public code repositories that mention the flaw appeared on October 29 and 30, and some claim to be proof-of-concept code; we have not tested them and cannot say whether any works. If you run your own Linux server, install your distribution's fixed kernel and reboot. If a host runs it for you, ask whether the fixed kernel is installed and the server restarted. If you run Ubuntu, ask your server admin whether to install the tested kernel now or wait for the regular update, and reboot either way.

What happened

What the flaw is. The kernel team's record describes a use-after-free in the part of the kernel that handles the start of an IPv4 TCP connection (the first exchange of packets when anything connects to a server). In plain words, two parts of the kernel use the same piece of memory, and one frees it while the other is still using it. The record's scoring notes say an attacker could reach it over the network with no login and no action by a user, and could crash the kernel or read and change its memory. The record says it affects Linux kernels from version 4.4 until fixed, and that IPv6 is not affected by the main flaw. (Linux kernel CVE record, kernel fix)
Fixed kernel versions. The kernel team lists fixes in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, and in the mainline kernel (the record lists 7.3; the Ubuntu and Debian trackers date the fix commit to the 7.3-rc7 release candidate). Most servers run a kernel built by their Linux distribution, whose version numbers do not match these, so check your distribution's own notice for this CVE. The record lists no fix for older lines such as 5.4, so a server on one needs its vendor to supply a patched kernel. (Linux kernel CVE record)
The scores differ. The kernel team's record rates it 9.8 out of 10 (critical). Red Hat now rates it Critical at 9.8 too, but its CVE page still names a system crash or memory corruption as the main result and says that reliably running code takes precise control of memory. Other vendors score it lower: Oracle lists a preliminary 8.1, Amazon lists 8.1, and Ubuntu lists High priority with 8.3 under the newer CVSS 4.0 scoring system (its page also shows a 9.8 under the older CVSS 3.1 system). We say "rated up to 9.8" because the scores depend on who is scoring and what they assume. (Linux kernel CVE record, Ubuntu, Oracle, Amazon Linux, Red Hat)
Anthropic's claim. In a post on October 27, 2026, Anthropic said its AI model Claude wrote an exploit that lets a remote attacker "run arbitrary commands as root, without any credentials or user interaction" on "Linux servers with a multipath TCP listener," and tied it to this CVE. Anthropic says that in its own proof of concept, it took 48 minutes to work out where the kernel sits in memory and five more to run a command, and that a failed attempt does not crash the machine, so an attacker can keep trying. The Hacker News reports the exploits were built in a lab and not seen in a real attack. The kernel's fix credits an Anthropic researcher as its reporter, which fits Anthropic's account. But the CVE record describes an IPv4 TCP flaw and never mentions multipath TCP, and we found no independent test showing the exploit works through this exact flaw. The AWS bulletin repeats that researchers demonstrated remote code execution against hosts with a multipath TCP listener, which is the same claim and not a separate test. Treat the root-takeover claim as Anthropic's, not independently confirmed. (Anthropic, The Hacker News, kernel fix)
No confirmed attacks. The AWS bulletin, last updated November 1, says AWS is "not aware of exploitation of this issue in the wild." CISA KEV lists no entry for this flaw in its version dated November 4, 2026, which we read directly from CISA's catalog file on November 4. We found no report that anyone is attacking it. Public code repositories about the flaw appeared on October 29 and 30. Brandefense said on October 31 that several of them publish proof-of-concept or trigger code, and that it had not verified a working exploit. We have not tested, described or linked any of them, and we found no exploit code published by Anthropic itself. The fix is public and Anthropic has described in general terms how its exploit works, so a server that has not updated should not wait. (CISA KEV, Anthropic)
Suspected scanning. In a post on November 2, Marcus Hutchins, a well-known security researcher, said he had picked up residential proxies and VPNs, some in Russia, scanning the internet on port 443 with multipath TCP connections and sending no web traffic. He says normal scanners do not do this, so he "strongly suspect[s]" it is scanning for this flaw, and that the use of residential proxies suggests attackers rather than researchers. Scanning is not an attack, and he does not report any break-in. His own scan on October 30 found about 2,102,043 servers reachable over multipath TCP on port 443, and about 762,774 on a deeper check that completed a secure web connection. He says neither number shows unpatched kernels, only exposure. He also says no public remote code execution exploit is known, but that several proofs of concept that only crash a server are circulating; we have not looked for or linked them. Ubuntu blog also says that, apart from Anthropic's unreleased exploit, no other exploit is known to have been made or published. Security.NL covered his findings on November 4. (Marcus Hutchins, Ubuntu blog, Security.NL)
Where fixes stand (checked November 1; Ubuntu and AlmaLinux checked November 4). These are the vendors' own pages, except Rocky Linux, which announced its fix in a post from its official account.
- Debian: Debian 13 and Debian 12 are fixed. Debian 13 ("trixie") has kernel 6.12.113-1 (security advisory DSA-6568-1, October 16) and Debian 12 ("bookworm") has 6.1.190-1. (Debian)
- Oracle Linux: fixed kernel errata for the Unbreakable Enterprise Kernel were released October 16 (ELSA-2026-500397, ELSA-2026-500398 and ELSA-2026-500399). Oracle's page lists only those kernel errata. (Oracle)
- Amazon Linux: fixed. Amazon Linux 2 and Amazon Linux 2023 both have fixed kernels. The AWS bulletin lists ALAS2-2026-4065 for Amazon Linux 2 (with ALAS2KERNEL-5.4-2026-135, ALAS2KERNEL-5.10-2026-137 and ALAS2KERNEL-5.15-2026-120 for its extra kernels) and ALAS2023-2026-3365, ALAS2023-2026-3335 and ALAS2023-2026-3251 for Amazon Linux 2023. Amazon Linux 2023 instances that are locked to a release version must use release 2023.12.20261102 or later to receive the updated kernel. (AWS bulletin, Amazon Linux)
- Ubuntu: fixes in testing. Ubuntu's blog of November 2 says fixed kernels for 22.04 (5.15.0-203.213), 24.04 (6.8.0-149.149) and 26.04 (7.0.0-43.43) are in its "-proposed" area while it finishes testing them on more than 2,000 certified machines, and that it will move them to the regular updates once tests are done. Packages from -proposed are not installed by default: an admin has to enable it and install the kernel on purpose, and a reboot is needed. The blog says 26.10 is fixed in 7.3.0-10.10, while Ubuntu's CVE page, updated November 4, still shows 26.10 as "work in progress" in that version. It lists 20.04, 18.04 and 16.04 as "fix pending"; those are covered under Ubuntu Pro. 14.04 is not affected. (Ubuntu blog, Ubuntu)
- Red Hat: fixed for Enterprise Linux 8, 9 and 10 on November 1, and a reboot is required. Red Hat now rates the flaw Critical (bulletin RHSB-2026-016, public October 30). For Enterprise Linux 8, RHSA-2026:93414 has kernel-4.18.0-553.182.1.el8_10, and RHSA-2026:93415 covers its real-time kernel. For Enterprise Linux 9, RHSA-2026:93412 has kernel-5.14.0-687.64.1.el9_8. For Enterprise Linux 10, RHSA-2026:93413 has kernel-6.12.0-211.72.1.el10_2. Enterprise Linux 7 and 6 are not affected. Red Hat's CVE page still lists the Enterprise Linux 9 real-time kernel, OpenShift Container Platform 4 and 5 and Red Hat Enterprise Linux for NVIDIA as affected, so those are not fixed yet. (Red Hat bulletin, Red Hat)
- Rocky Linux: fixed. On the evening of October 30, Rocky Linux's official account said kernels with fixes were in its production repositories and "should be showing up in a mirror near you within the next few hours." They are kernel-4.18.0-553.180.1.el8_10.0.1 for Rocky 8, kernel-5.14.0-687.61.1.el9_8.0.1 for Rocky 9 and kernel-6.12.0-211.69.1.el10_2.0.1 for Rocky 10. Your mirror may lag, so check that you can see the new kernel before you update. (Rocky Linux, CIQ)
- AlmaLinux: fixed. AlmaLinux said on November 2 that the fix is now in its regular kernel updates for AlmaLinux 8, 9 and 10, since kernel-4.18.0-553.182.1.el8_10, kernel-5.14.0-687.64.1.el9_8 and kernel-6.12.0-211.72.1.el10_2, and that the testing repository is no longer needed. AlmaLinux says it ships with multipath TCP turned off, but that systems without it still need the fix. (AlmaLinux)
Temporary mitigations, not a fix. Vendors have published interim steps for servers that cannot update and restart yet. They reduce exposure, they can block normal traffic, and they do not replace the update. Test each one on a non-production machine first. Installing the fixed kernel and rebooting is the only complete fix, and the vendors say so.
- Drop IPv4 packets that carry IP options. Red Hat gives this nftables rule, which goes inside the table and chain given in the Red Hat bulletin: ip protocol tcp ip hdrlength > 5 counter drop. Red Hat says it reduces exposure but cannot fully prevent the flaw, and that you should remove it after the kernel is updated. AWS gives this iptables example: iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP. AWS says it does not persist across reboots unless saved, and that Amazon Linux 2023 does not include iptables by default. AlmaLinux and CIQ each publish their own version of the nftables rule. (Red Hat bulletin, AWS bulletin, AlmaLinux, CIQ)
- Turn off multipath TCP: sysctl -w net.mptcp.enabled=0, then restart any service that still has a multipath TCP listener open. AlmaLinux lists open ones with sudo ss -lnMp, and Marcus Hutchins gives the same check as sudo ss -Mlnp. He stresses that the setting does not apply to sockets that are already open, so a service that is not restarted stays exposed. He notes that several kernels, including Debian's, turn multipath TCP on by default, and that programs built with Go 1.24 or newer, including the Caddy web server, open a multipath TCP listener by default when the kernel allows it. Ubuntu blog says the flaw is not specific to multipath TCP and that its security team believes security updates are "the only appropriate mitigation." Both agree on the main point: turning off multipath TCP is at most a stopgap, and the kernel update is the fix. Disabling multipath TCP on its own does not close the plain TCP path, so it is not enough. CIQ tested a plain TCP listener with multipath TCP off and it still answered a connection request that carried IP options. (AlmaLinux, AWS bulletin, CIQ)

Who should worry

This is about Linux servers that accept connections from the internet. Ask about this if any of these are true:

You rent or own a Linux server (a VPS, a cloud server or a dedicated server) that runs your website, store, email or other services.
Your website runs on a Linux server that an agency or developer looks after, and you have not heard whether the kernel was updated and the server restarted.
You run Ubuntu, whose fixed kernels are so far only in its -proposed testing area, or an older Ubuntu release whose fix is still pending.
Your server runs Debian, or a program built with Go 1.24 or newer such as the Caddy web server, which can open multipath TCP listeners by default.
You run Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, Amazon Linux, Debian or Oracle Linux and have not yet installed the fixed kernel and restarted.
You run containers or Docker. Containers share the server's kernel, so updating software inside a container does not fix this; the server underneath needs the new kernel.
You run a web agency or host and look after servers for clients.

If your site is on a hosted builder such as Shopify, Squarespace or Wix, keeping the servers updated is the provider's job, and you do not need to do anything. If you use shared or managed hosting, ask your host whether the new kernel is installed.

What to do now

Do these today. If this is not your area, send the message below to whoever runs your server.

Find out what you run. On the server, the command uname -r shows the kernel version. If your server runs an official kernel from kernel.org, compare it with the list above. If it runs a Linux distribution's kernel (almost everyone), check that distribution's notice for CVE-2026-98432 instead.
Install the fixed kernel. Use your distribution's normal update tool to install the kernel update once it is available (see the list above). Fixed kernels are out for Debian, Oracle Linux, Amazon Linux, Rocky Linux, AlmaLinux and Red Hat Enterprise Linux 8, 9 and 10. Ubuntu's are in testing (see the next step). For Amazon Linux, AWS gives sudo yum update kernel && sudo reboot for Amazon Linux 2 and sudo dnf update kernel --releasever=latest && sudo reboot for Amazon Linux 2023. Take a backup or snapshot first.
Reboot. A new kernel does not take effect until the server restarts. After the restart, run uname -r again and confirm it shows the new version. If your host offers live kernel patching, ask them to confirm it covers this CVE.
Running Ubuntu? For 22.04, 24.04 and 26.04, the fixed kernel is in Ubuntu's -proposed area. Your server admin can choose to enable it and install the kernel now, using the steps in the Ubuntu blog, or wait for the regular update, which Ubuntu says will follow once testing is done. Ubuntu notes that -proposed is meant for users who run their own kernel tests, so this is a judgment call for whoever runs the server. Either way, reboot afterwards and check uname -r. For 20.04 and older, the fix is still pending. Meanwhile, the temporary mitigations above are stopgaps, not a fix. Once the fixed kernel is installed and the server has restarted, remove any temporary firewall rule you added. (Ubuntu blog, Ubuntu)
If a host or agency runs your server, send the message below and ask for a yes or no, with the new kernel version.
Check your site afterwards. Load your main pages, test your forms and, if you sell online, place a test order. If your server crashes or restarts without a clear reason, tell your host, because crashing is one of the effects the kernel record describes.

What to send your developer, agency or host

The Linux kernel flaw CVE-2026-98432 was published on October 15, 2026. It is a use-after-free in IPv4 TCP connection handling that the kernel team says can be reached over the network with no login, and it is rated up to 9.8 out of 10. Fixed kernels are released for Debian, Oracle Linux, Amazon Linux, Rocky Linux and Red Hat Enterprise Linux; AlmaLinux has also released its fix, and Ubuntu's fixes are in its -proposed testing area. A security researcher reports internet-wide scanning that he suspects is looking for this flaw. If you turned off multipath TCP as a stopgap, please also restart the services that had multipath TCP listeners open (check with sudo ss -Mlnp). Please tell us which kernel version each of our servers runs (the output of uname -r), whether the fixed kernel is installed, and whether the server has been restarted since. If your distribution has no fix yet, please tell us when you expect it and how you are watching for it. Sources: Linux kernel CVE record, Anthropic.

Common questions

Has my server been hacked?

This notice does not mean your server has been hacked. It means a serious flaw is public and fixed kernels are out for most major distributions. We found no confirmed attacks, and CISA does not list the flaw as exploited. A researcher reports scanning he suspects is looking for this flaw; scanning is not a break-in. (Marcus Hutchins, CISA KEV)

Can EverThread tell me if I am affected?

No. EverThread does not test for this kernel flaw. We check your home page from the outside, the way a browser sees it. We cannot see which operating system or kernel version a server runs, or whether it has been updated and restarted. If our scan does not warn you about this, that does not mean your server is up to date. Our free scan does look at your home page for other common problems, such as an expired padlock certificate, missing browser safety settings and files that should not be public.

Is it really a 9.8?

That is the kernel team's score, and Red Hat, which now calls the flaw Critical, gives the same number. The score assumes the attack is easy to repeat. Other vendors score it between 8.1 and 8.3: Amazon and Oracle 8.1, and Ubuntu 8.3 on the newer CVSS 4.0 scale. Red Hat's CVE page still names a system crash or memory corruption as the main result and says reliably running code takes precise control of memory, while its bulletin says an attacker could "trigger remote code execution." Anthropic says it got full control in its own tests. These views do not agree, and we cannot settle them. The safe course is to update and reboot. (Linux kernel CVE record, Ubuntu, Oracle, Amazon Linux, Red Hat, Red Hat bulletin, Anthropic)

Does it only matter if I use multipath TCP?

No. Anthropic says its exploit worked against servers with a multipath TCP listener, but that is only the path its demonstration used. The flaw itself is in ordinary IPv4 TCP connection handling, when a connection request carries IP options. The Linux kernel CVE record does not mention multipath TCP, AlmaLinux says the bug is in the regular IPv4 TCP code, and CIQ found that a plain TCP listener still answered such a request with multipath TCP switched off. The kernel record says IPv6 is not affected by the main flaw. It also mentions a related, narrower IPv6 issue that it says will be fixed in a separate patch. Switching off multipath TCP removes the path Anthropic used and leaves the plain TCP path open. Do not assume you are safe because you do not use multipath TCP. Ubuntu says the same: the flaw is not specific to multipath TCP. (Anthropic, Linux kernel CVE record, AlmaLinux, CIQ)

Is this the same as the Linux kernel flaw in your PHP notice?

No. The kernel flaw in our PHP notice (CVE-2026-46300) is a different one, and Red Hat describes it as needing an attacker who is already on the server. This one is described as reachable over the network. Both need a kernel update and a restart.

Where can I see other notices?

All current notices are on our notices page.

Security alerts by email

Hear about the next one first.

When a flaw puts websites at risk, we send one plain-English email: what happened, who it affects and what to do. It's free, whether or not you use EverThread.

Sources

CVE Program: CVE-2026-98432, published by the Linux kernel team on October 15, 2026, checked November 1, 2026
Linux kernel: the fix, ipv4: free inet_opt and ireq_opt after an RCU grace period, checked October 29, 2026
Ubuntu: CVE-2026-98432, last updated November 4, 2026, checked November 4, 2026
Ubuntu: Fixes available in -proposed pocket for CVE-2026-98432, November 2, 2026, checked November 4, 2026
Marcus Hutchins: post on suspected scanning and exposure, November 2, 2026, checked November 4, 2026
Security.NL: Aanvaller zoekt op internet naar Linux-servers met kritiek TCP-lek (in Dutch), November 4, 2026, checked November 4, 2026
Debian: CVE-2026-98432 tracker and DSA-6568-1, October 16, 2026, checked November 1, 2026
Oracle: CVE-2026-98432, checked November 1, 2026
Amazon Linux: CVE-2026-98432, modified October 30, 2026, checked November 1, 2026
Amazon Web Services: CVE-2026-98432: Linux kernel IPv4 TCP use-after-free Issue (bulletin 2026-160-AWS), published October 30, 2026, last updated November 1, 2026, checked November 1, 2026
Red Hat: CVE-2026-98432, rated Critical, checked November 1, 2026
Red Hat: RHSB-2026-016: Use-after-free in kernel IPv4 (CVE-2026-98432), public October 30, 2026, checked November 1, 2026
Red Hat: errata RHSA-2026:93412, RHSA-2026:93413, RHSA-2026:93414 and RHSA-2026:93415, issued November 1, 2026, checked November 1, 2026
Rocky Linux: post from the official Rocky Linux account on the fixed kernels, October 30, 2026, checked November 1, 2026
AlmaLinux: CVE-2026-98432: Patched kernels released, October 30, 2026, updated November 2, 2026, checked November 4, 2026
CIQ: Mitigating CVE-2026-98432 on Rocky Linux 8, 9, 10, and LTS Variants, October 30, 2026, checked November 1, 2026
Brandefense: CVE-2026-98432 Linux Kernel Flaw, last updated October 31, 2026, checked November 1, 2026
Anthropic: Discovering and exploiting vulnerabilities in critical, real-world software with Claude, October 27, 2026, checked November 1, 2026
The Hacker News: Anthropic's Unreleased AI Model Chains Flaws Into Working Chrome, Safari, Windows and Linux Exploits, October 28, 2026, checked October 29, 2026
CISA: Known Exploited Vulnerabilities Catalog, catalog version dated November 4, 2026, read from CISA's own catalog file November 4, 2026; no entry for CVE-2026-98432