# CVE-2026-98432: check your Ubuntu VPS and reduce exposure

A kernel vulnerability cannot be fixed in package.json. After the CVE-2026-98432 alert, we checked two Ubuntu VPS instances and applied targeted mitigation. Here is our approach, the useful commands and the limits that matter.

The goal is to reduce exposure while waiting for a patched kernel, then verify that services remain accessible. This article documents an actual intervention; adapt the configuration to your own server.

## Status on 31 October 2026

The Ubuntu tracker checked on 31 October still lists a fix as work in progress for the linux package on Ubuntu 26.04 LTS. This can change: check the entry for your release and kernel flavour before deciding what to do.

CVE-2026-98432 affects IPv4 TCP connection handling in the Linux kernel. A memory safety flaw can be exploited remotely. The publicly described code execution chain uses an MPTCP listener, but the underlying flaw is not specific to MPTCP.

[Check the current Ubuntu status](https://ubuntu.com/security/CVE-2026-98432)

## Start by checking your VPS

These commands identify the running kernel, distribution, two network settings and listening MPTCP sockets. They do not change the configuration. If your version of ss lacks MPTCP support, an error does not mean that the server is protected.

Compare the results with your distribution’s security tracker. A kernel version copied from a social media post is not enough: distributions can backport fixes into their own packages. An installed package is not necessarily the kernel currently running, either.

```bash
uname -r
cat /etc/os-release
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
sudo ss -M -l -n -p
```

## What we changed on our two VPS instances

On 30 October, we audited our two Ubuntu VPS instances and applied targeted temporary measures. We added a dedicated filter for IPv4 TCP packets carrying IP options and disabled the creation of MPTCP sockets in the relevant network namespaces.

One Caddy service had a controlled restart to recreate its sockets with the adjusted setting. The five existing containers kept their processes and start times. We then checked fresh SSH connections and received HTTPS 200 responses from all seven sites we tested.

We did not upgrade the operating system or reboot either VPS. These results describe our checks after the intervention; they do not prove that every possible exploitation path is blocked.

## Filter IP options with a separate rule set

This is the structure of our filter, using an example table name. The first rule limits logging; the second drops every matching packet even after that limit is reached. IP options differ from ordinary TCP options such as MSS or SACK.

Treat this as an example to review and integrate into your existing firewall, with recovery access and a scoped rollback ready. Do not replace your whole configuration. Check any special network requirements, including IP options used for security labelling.

This filter targets IPv4. We describe it as exposure reduction, without a guarantee that it covers the vulnerability completely.

```nft
table inet cve_2026_98432 {
  chain prerouting {
    type filter hook prerouting priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 limit rate 5/minute burst 5 packets log prefix "CVE98432 IPopts " level warn
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}
```

## Disable MPTCP if you do not use it

If your services do not need MPTCP, this setting prevents new MPTCP sockets in the current network namespace. It does not close sockets that are already open. Check the sockets again and plan restarts only for the affected services.

To keep this setting at boot, add net.mptcp.enabled = 0 to a dedicated sysctl.d file after checking the existing settings. Persistence should then be tested during a planned reboot.

```bash
sudo sysctl -w net.mptcp.enabled=0
```

## Check services written in Go too

Go 1.24 enabled MPTCP by default for ListenConfig on supported systems. A reverse proxy written in Go therefore deserves checking even when your application uses Node.js.

The setting below changes that default when supplied in the service environment. Preserve any other GODEBUG values and recreate the affected process’s sockets. We used it for Caddy; it does not replace a kernel fix.

```text
GODEBUG=multipathtcp=0
```

## Docker: the host setting is only part of the check

The MPTCP setting belongs to each network namespace. A zero value on the host therefore does not establish that every container has the same configuration.

We checked the existing namespaces and added a periodic check for new ones. A test using a namespace created after activation confirmed that it was handled. This check is periodic, so there is a delay before it applies, which is one reason we also keep filtering at the host’s ingress.

Some previously opened internal container sockets can remain. We distinguished those sockets from public listeners instead of treating a system setting as evidence that every socket had disappeared.

## How we checked the mitigation

We checked that the filter was loaded, inspected its counters, and reviewed MPTCP settings and listeners. A non-exploit diagnostic packet confirmed that the drop rule was reached. We did not run exploit code.

We also opened a fresh SSH connection and checked the sites externally. Existing firewall rules were preserved. Persistence mechanisms were configured and reloaded, but we did not test them after a full VPS reboot.

An increasing counter establishes that a packet matched a rule. It proves neither an intrusion attempt nor complete protection: our own diagnostic checks can also increase it.

## Next: boot into a patched kernel

Your distribution’s official fix remains the priority. When it becomes available for your system, plan its installation and the required reboot, then verify the actual running kernel with uname -r. Decide whether to remove temporary measures based on the official status and your services’ requirements.

This work concerns the Linux infrastructure hosting your applications. An npm update to PRNext cannot patch a VPS kernel. Self-hosting also means following this layer of the system and checking changes against real services.

[Read next: deploying an application on a VPS](/blog/deploy-nextjs-vps)

## Sources

[Ubuntu · CVE-2026-98432](https://ubuntu.com/security/CVE-2026-98432)

[Go · Security team analysis](https://github.com/golang/go/issues/82717)

[Go 1.24 · net / ListenConfig](https://go.dev/doc/go1.24#net)

[Linux · MPTCP sysctl](https://docs.kernel.org/networking/mptcp-sysctl.html)

[Netfilter · nftables manual](https://netfilter.org/projects/nftables/manpage.html)

Published: 2026-10-31

Modified: 2026-10-31

Author: PRNext

---

Language: en

Canonical: https://prnext.dev/blog/cve-2026-98432-ubuntu-vps-mitigation

Index: https://prnext.dev/llms.txt