A Linux server can have updated packages and still be running a vulnerable kernel. That is the first gap to close when checking CVE-2026-98432.
The vulnerability received renewed attention after Anthropic’s October 27 research report described remote code execution against a Linux server with a Multipath TCP listener. For a VPS administrator, the useful question is more specific: does this kernel need a fix, and has that fix actually taken effect?
- What CVE-2026-98432 means for a VPS
- Why MPTCP matters—and what its setting cannot prove
- Inspect your server without changing it
- 1. Identify the distribution and running kernel
- 2. Read the MPTCP setting
- 3. Inventory listening TCP services
- Read the vendor status before choosing an update
- Turn the findings into a maintenance decision
- Check your understanding
- Primary sources and verification scope
What CVE-2026-98432 means for a VPS
The issue involves a race condition in Linux networking: one execution path can release memory while another still uses it. This is a use-after-free. Ubuntu’s advisory describes the affected handling of IPv4 options during TCP connection setup and related request migration.
That happens inside the kernel. Updating a web application, replacing an HTTPS certificate or restarting PHP does not replace the affected kernel code.
For a virtual machine, investigate its guest kernel as well as the provider’s responsibilities. For a container sharing a host kernel, the host administrator controls the kernel fix; updating packages inside that container is insufficient. Establish which environment you have before choosing an update procedure.
| Evidence | What it tells you | What it does not establish |
|---|---|---|
| A vendor marks a kernel affected | That product needs the vendor’s stated remediation. | That every affected server can be exploited in the same way. |
| Anthropic reports remote root with an MPTCP listener | A serious attack scenario reported by the researchers. | That every ordinary TCP listener has the same demonstrated exploit path. |
| A kernel update is installed | A package is present on disk. | That the running kernel contains its fix. |
Sources: Ubuntu’s CVE entry and Anthropic’s research report. This article does not independently reproduce the reported exploit.
Why MPTCP matters—and what its setting cannot prove
Multipath TCP lets one connection use more than one network path. A device might combine two links or continue a connection when one path fails. Linux implements it through MPTCP sockets and underlying TCP subflows; the kernel’s MPTCP documentation explains that relationship.
Three conditions are easy to confuse: the kernel supports MPTCP, MPTCP socket creation is enabled, and an application has actually opened a reachable MPTCP listener. The first two do not prove the third.
Disabling MPTCP should not be presented as a complete fix for this CVE. The documented bug concerns shared TCP code. Treat any proposed workaround as a change requiring vendor guidance and application compatibility checks.
Inspect your server without changing it
Run these commands on the Linux system you administer. In a container, some results describe the container’s environment while the kernel belongs to the host. Record that distinction. The examples below illustrate interpretation; they are not results from a tested vulnerable server.
1. Identify the distribution and running kernel
cat /etc/os-release
uname -rThe first command identifies the operating-system release. The second prints the running kernel release. Save both in your maintenance notes, including any cloud, HWE, real-time or other kernel flavour.
A release string alone is insufficient for a verdict. Distributions can backport security fixes while retaining an older upstream version number. Compare the full package build with your vendor’s advisory; Red Hat’s explanation of backporting shows why a simple version comparison can mislead.
2. Read the MPTCP setting
sysctl net.mptcp.enabledAn illustrative result is:
net.mptcp.enabled = 1
According to the
kernel’s sysctl documentation,
this permits MPTCP socket creation in the current network namespace.
It does not identify a listening application. A value of
0 does not prove the kernel is patched. An unknown-key
error also needs investigation rather than a “safe” label.
If services use separate network namespaces, checking only your shell’s namespace leaves gaps. Ask the host or platform administrator to inspect the relevant service environment.
3. Inventory listening TCP services
ss -lntpThis requests listening TCP sockets, numeric addresses and ports, and process details where permissions allow. Missing process names may reflect permissions. See the ss manual for the options.
A listener on 0.0.0.0:443 accepts connections across
the machine’s IPv4 addresses, subject to network controls.
It does not prove Internet reachability or identify an MPTCP
listener. Review service configuration and any software that
enables MPTCP; do not classify sockets by their port number alone.
Match your listener inventory to host firewalls, cloud security groups, load balancers and routing. If the distinction is unfamiliar, read how Linux listening ports and sockets work.
Read the vendor status before choosing an update
At the October 30 check, Ubuntu’s entry, last updated October 29,
still marked the standard linux package for Ubuntu
22.04, 24.04, 26.04 and 26.10 as vulnerable, with work in progress.
The tracker lists cloud and other kernel flavours separately.
“Work in progress” is not a released fix. Reopen the live advisory before acting. Package availability may change after this article’s check.
| Your environment | Check here | Evidence to record |
|---|---|---|
| Ubuntu kernel | Ubuntu CVE tracker | Release, kernel source package, status and released fixed build, if available. |
| Red Hat Enterprise Linux | Red Hat CVE entry | Exact product and applicable security advisory. Do not substitute Ubuntu’s result. |
| Provider-managed or custom kernel | Your provider’s security notice or support channel | Whether this exact build is affected and how its fix is activated. |
| Live-patched kernel | Your live-patch provider’s CVE coverage and status tools | Explicit coverage for this CVE and confirmation that the patch is applied. |
Installing every currently offered update may still leave you waiting for a fix. In that case, keep an owner and a follow-up time for the issue; do not close it merely because the package manager reports nothing pending.
Turn the findings into a maintenance decision
Consider this hypothetical example: a VPS owner
installs a kernel security update but postpones the reboot.
The service keeps running normally. A later inspection shows
that uname -r still identifies the earlier kernel,
and no live patch covers the CVE. The update is installed,
but its kernel replacement is not active. The next task is
a controlled boot into the fixed build.
Another server may have an older-looking version string with a vendor-confirmed backport. Installing a random newer upstream kernel would add risk without answering the original question. Evidence from the vendor changes the decision.
- Establish responsibility. Identify who controls the running kernel: you, a host administrator or a managed-service provider.
- Confirm the supported fix. Match the exact product and kernel flavour to a released advisory. If no fix is available, request vendor-approved interim measures and review unnecessary exposure.
- Prepare recovery. Verify backups, provider-console access and the supported recovery procedure. Record critical service checks before changing the server. Use the Linux server change checklist to prepare the maintenance window.
- Apply and activate. Follow the distribution’s update procedure. Boot into the replacement kernel when required, or verify explicitly supported live-patch coverage. A service restart cannot activate a replacement kernel.
- Verify the result. Recheck the running kernel or live-patch state against the advisory, then test SSH access, application responses, monitoring and expected listeners.
- Document exceptions. If recovery requires returning to an affected kernel, record the renewed exposure and arrange another supported remediation path.
For a fuller explanation of installed versus active fixes, use the Linux kernel security checklist.
Check your understanding
MPTCP is enabled. Does that prove a vulnerable listener is exposed?
No. The setting permits socket creation in that namespace. Application use, reachability and the running kernel’s patch status require separate evidence.
The kernel update installed successfully. Can you close the issue?
Only after confirming that the relevant fix is active. Check the running build or verified live-patch coverage, then check service health.
The kernel number looks older than an upstream fixed version. Is it affected?
Not necessarily. A distribution may have backported the fix. Match the complete vendor build and advisory rather than comparing only upstream numbers.
No fix is offered by the package manager. What next?
Check the product’s advisory and support status. Confirm that the right repositories and kernel flavour are involved, then follow vendor guidance while tracking remediation.
Primary sources and verification scope
- Anthropic: discovering and exploiting vulnerabilities — October 27 report; the Linux section describes the researchers’ MPTCP attack scenario.
- Ubuntu: CVE-2026-98432 — technical description and kernel-package status.
- Red Hat: CVE-2026-98432 — product-specific assessment and advisory information.
- Linux kernel: Multipath TCP and MPTCP sysctl variables — protocol model and configuration scope.
- ss manual and Red Hat’s security backporting practice — inspection options and version interpretation.
Advisory status was checked on October 30, 2026. Examples are illustrative. No exploit reproduction, production-server scan or Linux command execution is claimed for this walkthrough. Consult the linked vendor entry again before making a change.
