[Urgent Patch] CVE-2026-98432 — Anthropic PoC Succeeds 12 Days After Disclosure
An impact check and response guide for Linux server operators and Go service developers
Contents
When an operator reading a kernel security notice runs into the words “remote root execution,” they tend to stop what they are doing. The first questions are whether our servers are affected and whether a reboot has to be scheduled today. Developers who build services in Go get one more question on top of that: we have never used MPTCP, so why is Go part of this story?
CVE-2026-98432 is exactly that kind of case. After the Linux kernel CVE notice came out on October 15, Anthropic announced on the 27th, 12 days later, a demonstration of remote root command execution using this vulnerability. The “12 days” in the title is the gap between the two disclosure dates. It does not mean the exploit took 12 days to develop, or that it first succeeded on the 27th. Linux kernel notice, Anthropic announcement
The first thing to check is the running kernel on your Linux servers. If you operate Go services, you also need to look at which sockets they actually open. There are several conditions in between, so the language name alone is not enough to decide whether you are affected.
01 From a memory-release notice to a remote root execution demo
The title of the first notice was fairly dry: memory for options used by IPv4 connections would be freed after the RCU grace period. The change that caused the bug went into Linux 4.4. Kernel bug description
The problem arose when several tasks shared the same memory. While one task handling a TCP connection was still reading the option memory, another task could free it. That is a Use-After-Free: reusing memory that has already been returned. The fix delays the release until other tasks have finished reading.
The announcement on the 27th, however, showed commands being executed through this bug. Anthropic said it sent packets to a Linux server accepting MPTCP connections and executed commands with root privileges, without any login credentials or user clicks. In the research team’s test environment, obtaining kernel address information took 48 minutes, and executing commands took another 5 minutes after that. Reading the whole attack as “done in 5 minutes” leaves out the first 48 minutes. Anthropic’s Linux demonstration
| Date | What was disclosed |
|---|---|
| October 15 | The Linux kernel CVE team announced the bug and the fixed versions. |
| October 27 | Anthropic announced an unauthenticated remote root command execution demonstration targeting MPTCP listeners. |
| October 30 (KST) | The Go security team’s guidance on MPTCP use and kernel updates was forwarded to oss-security. |
The sources for the timeline are the Linux notice, the Anthropic announcement, and the forwarded Go security team notice. An attack demonstrated in a research environment and whether a production server has actually been compromised have to be assessed separately.
02 Why Go services deserve a second look
MPTCP is a TCP extension that uses several network paths for a single connection. Linux supports it, but kernel support does not mean every service automatically accepts MPTCP connections. The application has to use an MPTCP socket. Linux MPTCP documentation
This is where Go’s defaults matter. Starting with Go 1.24, listeners that accept connections use MPTCP by default. If the kernel supports it and the program is subject to that default, it may be using MPTCP even though the developer never implemented anything MPTCP-specific. The actual behavior depends on the Go version used for the build, the compatibility settings in go.mod, GODEBUG, and per-socket settings, taken together. Go defaults and compatibility
In other words, the list of features developers remember is not enough to settle the question. The build settings may have changed even if the service code did not, and programs run by other teams on the same server may be accepting connections too.
The published Anthropic demonstration required an MPTCP listener that the attacker could reach. That does not mean servers without an MPTCP listener can be left out of patch review. The Go security team explained that the underlying bug is not limited to MPTCP and that similar attacks may be possible on systems without an MPTCP listener. Go security team guidance
03 Before fixing, check whether your servers are affected
Server operators check the kernel and packages; Go developers check the executables and service settings. The steps below are based on ZIEN Lens’s affected-version and per-distribution patch guide. This procedure checks the scope of impact and the publicly known attack path. It is not a test that runs exploit code to decide whether a system is vulnerable.
Start with the distribution and the running kernel
Check the basic information on the server with these two commands.
cat /etc/os-release
uname -rThen compare the name and release number of the kernel package actually installed with the fixed package in your distribution’s security notice. On Ubuntu, also distinguish whether it is the generic linux kernel, an HWE kernel, or a cloud kernel such as linux-gcp. Even with the same distribution name and OS version, the package to check can differ.
Comparing only the numbers against the upstream fixed version can lead to the wrong conclusion. Distributions sometimes keep the existing kernel version and only apply the security fix. Conversely, if a notice says “fix in progress,” that does not mean a fixed package is available to install yet. Per-distribution items to check
Look at the MPTCP setting and actual listeners separately
You can query the MPTCP setting of the current network namespace as follows.
sysctl net.mptcp.enabledA value of 1 means MPTCP sockets can be created. This value alone does not tell you that an MPTCP service is running or exposed to the outside. In environments with separate network namespaces, such as containers, you also need to check the setting in the namespace where the service runs. Linux MPTCP sysctl documentation
On kernels and iproute2 versions that support MPTCP diagnostics, a listener query can also help.
sudo ss -M -l -n -pMatch the address, port, and process of each socket shown against your service list, and use your firewall and port exposure settings to confirm whether it is a path an attacker can reach. If the command is not supported or the output is empty, first check the tool’s support and the namespace. Do not declare the whole server safe based on empty output alone. ss options
Go developers check the settings of the deployed program
It is easy to stop after checking the Go version installed on a development PC. What matters here is which Go version and settings were used to build the executable actually deployed on the server. Check the version in the build records, and review the project’s go.mod and go.work, any //go:debug directives, and GODEBUG in the service’s runtime environment. Also check whether the code calls net.ListenConfig.SetMultipathTCP directly. Go compatibility settings, Go socket API
Record the results in two parts. One is whether the fix has been applied to the kernel; the other is whether there is an externally reachable MPTCP listener, the condition of the published demonstration. Not finding the second condition is no reason to skip checking the first.
04 The fix is to change the running kernel
Once you actually start responding, there is a hurdle before any command: there may not yet be a fixed package for your server, or the package is out but it is hard to schedule a reboot. Seeing “fixed” in the kernel notice does not mean the work on your production servers is finished.
First, check your vendor’s notice to see whether a fix is available for the kernel package in question. If it is, update to that package and, in the usual kernel replacement procedure, reboot into the new kernel. If you use live patching, check whether it supports this CVE and whether it has actually been applied. The Linux kernel team also recommends updating to a kernel that includes the fix. Linux kernel recommendation, ZIEN Lens procedure for confirming the fix
When operators share their results, it helps to go one line further than “package installed”: record which kernel the server booted into and whether the services respond normally. Checking uname -r again after the reboot and comparing it with the fixed package catches the case where the package was installed but the old kernel is still running.
At this stage, Go developers need to confirm the same result as the server operators. Upgrading Go or redeploying the application does not fix a bug in the Linux kernel. If the fix for this CVE has been applied to the running kernel, you do not also have to change Go code or disable MPTCP to respond to this vulnerability.
05 If you cannot patch right away, where to start
When operators hear that a patch is not out yet, they start wondering what to do while they wait. That feeling showed in the community reaction too. On Reddit’s r/sysadmin, a post asking how common MPTCP-using programs are drew comments urging people to act first.
Paraphrased, u/pdp10’s comment reads:
“Remember, everyone: act now, and worry about the fallout later.”
— u/pdp10, r/sysadmin comment
The urgency is understandable, but you still need to know what connections your services accept. If your check finds an externally reachable MPTCP listener, you can consider restricting the network path so that only necessary access remains, or temporarily turning off MPTCP. After the change, confirm that new connections work and that the service behaves normally. These measures reduce exposure to the published attack path; they are not a completion criterion that replaces the kernel patch. Conditions of the attack demonstration, How Linux MPTCP works
For Go programs, GODEBUG=multipathtcp=0 turns off the MPTCP default. It has to be set in the environment that actually starts the service, followed by a restart, and you need to check whether explicit socket settings in the code override it. Changing an environment variable in one terminal does not change a service that is already running. Go settings, Per-socket settings
If you apply a temporary measure, it is a good idea to also schedule a date to check again whether a fixed package is out. Once the service is running normally and the alerts have gone away, a postponed kernel update is easily pushed aside by other work. Record the temporary measure and the completed kernel patch separately so that the next person in charge knows where things stand.
06 Summary
On first reading this notice, the urge is to check “do we use Go?” But when you lay out your server list, the programming language alone does not give the answer. You need to check which kernel is running, whether that package includes the fix, and which programs actually accept MPTCP connections.
When Linux operators and Go developers compare their findings, the conversation gets much shorter. Operators bring the running kernel and patch status; developers bring the build settings and listeners of the deployed programs. If there is no fixed package, agree on a temporary measure and a date to check again; if there is, apply it and then check the services as well.
The 48 minutes and 5 minutes of the attack demonstration catch the eye. In operations, what takes longer may be scheduling the reboot, confirming that services come back up properly, and reconciling results between the people in charge. Once that is done and you can write down “this server is running a fixed kernel,” you can close this notice.
