# Xray’s Emergency Update: How to Fix CVE-2026-98432 on Linux

CVE-2026-98432 exposes Linux TCP servers to remote root attacks. Check Xray and Go MPTCP settings, find kernel fixes, and verify remediation.

Canonical URL: https://aiidelist.com/blog/cve-2026-98432-xray-go-mptcp-linux-fix

Language: en

Published: 2026-10-31

Updated: 2026-10-31

## Key Takeaways

- **CVE-2026-98432 is a Linux kernel vulnerability.** Application updates can reduce exposure, but the underlying operating system needs a patch.
- **Anthropic demonstrated remote root command execution against a server with an MPTCP listener.** That finding does not establish identical exploitability across every Linux deployment.
- **Xray-core v26.10.31 disables MPTCP by default.** Its release announcement also confirms the withdrawal of v26.10.29.
- **Go 1.24 introduced default MPTCP listening behavior on supported Linux systems.** Actual behavior also depends on build defaults, application settings, and kernel support.
- **Disabling MPTCP is an interim mitigation.** Complete remediation requires a vendor-confirmed kernel fix that is active on the running system.

**Updated November 1, 2026.** The [Xray emergency release](https://github.com/XTLS/Xray-core/releases/tag/v26.10.31) explicitly recommends both upgrading Xray and updating Linux. Treat these as separate maintenance tasks. 

## What Is CVE-2026-98432?

CVE-2026-98432 is a use-after-free flaw in Linux IPv4 TCP connection handling. Under particular timing conditions, one execution path can free connection-option memory while another still accesses it.

The relevant kernel change dates back to Linux 4.4. This identifies the origin of the defect; it does not mean every subsequent kernel remains vulnerable after security updates.

Severity labels vary between vendors:

| Publisher | Published assessment | Interpretation |
| --- | --- | --- |
| Ubuntu | CVSS v3.1: 9.8 Critical; Ubuntu priority: High | CVSS severity and distribution patch priority are separate fields |
| Amazon Linux | CVSS v3: 8.1; Important | Its vector assigns high attack complexity |
| Red Hat | Critical impact | Its bulletin describes unauthenticated remote code execution risk |

These assessments are documented in the [Ubuntu tracker](https://ubuntu.com/security/CVE-2026-98432), [Amazon Linux tracker](https://explore.alas.aws.amazon.com/CVE-2026-98432.html), and [Red Hat bulletin](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016). A single score should not be presented as a unanimous vendor assessment. 

## How the Kernel Bug Works

The defect concerns ownership and lifetime of IPv4 option data during connection establishment.

1. A pending connection holds IPv4 options.
2. The kernel transfers those options to a newly created socket without duplicating them.
3. Another CPU can concurrently prepare a response to a retransmitted connection request.
4. If the new socket is destroyed first, that response path can access freed memory.

The fix replaces immediate deallocation in relevant paths with `kfree_rcu()`, delaying reclamation until existing RCU readers can finish. The [Linux kernel CVE announcement](https://lists.openwall.net/linux-cve-announce/2026/10/15/1) also identifies a related request-migration path. 

An operational consequence follows: application authentication cannot be relied on to stop a flaw reached while the kernel establishes the connection. An HTTP login page is downstream of that processing.

## What Anthropic Actually Demonstrated

In its [October 27 research report](https://www.anthropic.com/research/discovering-vulnerabilities-with-claude), Anthropic described an internal, unreleased research model producing an exploit against Linux servers exposing an MPTCP listener.

The reported chain first disclosed a kernel address to defeat address randomization, then achieved attacker-chosen command execution as root.

The timing needs careful interpretation:

| Reported stage | Time in the demonstrated PoC |
| --- | --- |
| Obtain a kernel pointer | 48 minutes |
| Reach command execution afterward | Another 5 minutes |

**These are PoC execution times, not the time Claude needed to discover the vulnerability or develop the exploit.** They are also not a universal compromise estimate.

Anthropic reported that unsuccessful race attempts could fail the handshake without crashing the system, allowing retries. Its demonstration establishes a serious exploitation capability; it does not, by itself, establish widespread attacks in the wild. 

## Why Go 1.24 Brought MPTCP Into Focus

Multipath TCP allows a connection to use multiple network paths. Applications can request an MPTCP listener even when their ordinary clients use conventional TCP.

The [Go GODEBUG documentation](https://go.dev/doc/godebug) describes these defaults:

| Setting | Default behavior requested |
| --- | --- |
| `multipathtcp=0` | Disable MPTCP for listeners and dialers |
| `multipathtcp=1` | Enable it for listeners and dialers |
| `multipathtcp=2` | Enable it for listeners only |
| `multipathtcp=3` | Enable it for dialers only |

Go 1.24 introduced `multipathtcp=2` as its default. However, Go compatibility settings can depend on the module or workspace Go version and explicit build directives. **The compiler version alone is insufficient evidence of the effective configuration.** 

There is another distinction: the [Go networking API](https://pkg.go.dev/net#ListenConfig.SetMultipathTCP) allows an application to override the default for individual listeners using `SetMultipathTCP`. It also documents fallback to TCP when MPTCP is unavailable or unsupported by a client.

Consequently, observing ordinary TCP client traffic does not prove that the server was configured without MPTCP. 

## What Xray-core v26.10.31 Changes

[Xray PR #7291](https://github.com/XTLS/Xray-core/pull/7291/files) changes the default listener configuration. The essential behavior is:

```go
lc.SetMultipathTCP(false)

if sockopt != nil {
    lc.SetMultipathTCP(sockopt.TcpMptcp)
}
```

This is an excerpt of the relevant behavior, not a complete listener implementation.

The default becomes disabled, but an explicit configuration can still enable MPTCP. Administrators should therefore inspect any existing `tcpMptcp` setting after upgrading.

For panel-managed installations, verify the actual Xray executable launched by the panel. Updating a management interface does not establish that its bundled core was replaced or its running process restarted. 

## Which Deployments Deserve Priority?

Prioritize systems by reachable services and running kernel status.

| Deployment | Recommended investigation |
| --- | --- |
| Public Linux VPS running Xray | Check the core version, explicit MPTCP settings, and kernel patch status |
| Caddy or Traefik on Linux | Inspect the deployed build and effective listener configuration |
| Other Linux TCP services | Check kernel status even when the application does not use Go |
| Containers on a Linux host | Include the host kernel and relevant container network namespaces |
| Android proxy applications | Inspect LAN-accessible inbound listeners and the device kernel |
| Managed hosting | Establish which infrastructure updates the provider performs and which remain the customer's responsibility |

The [MPTCP project's application inventory](https://github.com/multipath-tcp/mptcp.dev/blob/main/apps.md) lists default enablement beginning with Caddy v2.10.0 and specified Traefik releases, including v2.11.26 and v3.4.2. These entries help identify candidates for investigation; they are not a deployment-specific vulnerability verdict. 

Xray's release notice separately flags Android clients that expose Socks or HTTP inbound services to a local network. A client application can still create an inbound attack surface.

The [Go Security Team's advisory](https://groups.google.com/g/golang-announce/c/PCoQcdxoScw/m/aD-MgXEvAAAJ) states that the underlying bug is not MPTCP-specific. It cautions that systems without MPTCP listeners may be vulnerable to other exploitation paths. 

## Which Linux Kernel Versions Contain the Fix?

The maintained [kernel CVE record](https://kernel.googlesource.com/pub/scm/linux/security/vulns/+/refs/heads/master/cve/published/2026/CVE-2026-98432.mbox) lists these upstream fixed releases:

| Kernel branch | Recorded fixed release |
| --- | --- |
| 5.10 | `5.10.272` |
| 5.15 | `5.15.223` |
| 6.1 | `6.1.190` |
| 6.6 | `6.6.159` |
| 6.12 | `6.12.113` |
| 6.18 | `6.18.56` |
| 7.2 | `7.2.10` |
| 7.3 | `7.3` |

The initial announcement already identified the mainline fix in `7.3-rc7`. Production users should follow their supported distribution update channel. 

**Upstream version numbers are not a universal scanner rule.** Distributions can backport a fix while retaining an older base version.

The vendor records reviewed for this article show:

| Distribution | Published status | Practical action |
| --- | --- | --- |
| Debian Bookworm | Security source package `6.1.190-1` marked fixed | Install the corresponding supported kernel packages |
| Debian Trixie | Security source package `6.12.113-1` marked fixed | Verify the running kernel after activation |
| Amazon Linux 2 and 2023 | Fixed package advisories listed | Match the advisory to the installed kernel stream |
| Ubuntu | Several kernel packages still listed as vulnerable or work in progress | Check the exact release and kernel flavor |
| AlmaLinux 8, 9, and 10 | October 30 announcement provides testing-repository builds | Check for production availability before selecting packages |
| RHEL | Bulletin states fixes are being expedited | Follow the applicable product erratum |

The [Debian tracker](https://security-tracker.debian.org/tracker/CVE-2026-98432) reports source-package versions, which are not necessarily identical to `uname -r` output. AlmaLinux's [patch announcement](https://almalinux.org/ca/blog/2026-10-30-cve-2026-98432/) explicitly distinguishes testing builds from production releases. Package status can change after this article's update date. 

## Step 1: Inventory the Running System

Run these read-only checks on each relevant Linux host:

```bash
uname -r
cat /etc/os-release
sysctl net.mptcp.enabled
sysctl net.ipv4.tcp_migrate_req
```

For an Xray installation where the executable is on the command path:

```bash
xray version
```

Interpret the results carefully:

- `uname -r` reports the running kernel, not every kernel installed on disk.
- `net.mptcp.enabled=1` permits MPTCP socket creation; it does not prove that a listener exists.
- `net.mptcp.enabled=0` does not establish that the kernel defect is patched.
- A missing MPTCP sysctl can indicate unavailable support or a restricted environment. It is not a general CVE clearance result.
- `tcp_migrate_req=0` does not eliminate the separate retransmitted-request path.

The [kernel MPTCP documentation](https://docs.kernel.org/networking/mptcp-sysctl.html) identifies `net.mptcp.enabled` as a **per-network-namespace** setting. Checking the host namespace alone does not establish the configuration of every container. 

Record the distribution, kernel package, running kernel, service executable, and reachable interfaces together. This makes later verification reproducible.

## Step 2: Reduce MPTCP Exposure Where Appropriate

If the workload does not require MPTCP, temporarily prevent new MPTCP sockets in the current network namespace:

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

This changes a runtime setting. Persist it through the system's normal configuration management if it must survive reboot.

Because the documented setting controls socket creation, do not assume changing it has replaced existing listeners. Arrange controlled service restarts and verify their configuration afterward. Apply the same assessment to separate network namespaces.

For a Go service, set the environment in its actual service manager. Running an export in an unrelated SSH shell does not update an already-running daemon.

For example, replace `example.service` with the real systemd unit:

```bash
sudo systemctl edit example.service
```

Add this drop-in configuration:

```ini
[Service]
Environment="GODEBUG=multipathtcp=0"
```

If `GODEBUG` already contains necessary settings, preserve them in the comma-separated value and change only the relevant entry.

Then reload and restart during the planned maintenance window:

```bash
sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl is-active example.service
```

A successful restart establishes service availability, not complete remediation. Application calls to `SetMultipathTCP(true)` override this environment default, and inherited or externally managed listeners need separate inspection.

The Go Security Team describes per-program disabling as fragile: overlooking one exposed listener can leave the demonstrated attack conditions in place. **Keep the kernel update scheduled even after applying this mitigation.**

## Step 3: Update Xray and Activate the Kernel Fix

Upgrade Xray through its existing package, container, or panel management workflow to v26.10.31 or a subsequent release retaining the mitigation.

Then install the kernel package identified by the distribution's CVE advisory. A generic package update is not sufficient evidence if the fixed package is unavailable, held back, or belongs to a different kernel flavor.

Recommended deployment checks include:

1. Confirm the package advisory explicitly covers CVE-2026-98432.
2. Confirm the package matches the host's architecture and kernel stream.
3. Arrange console access and a rollback option before rebooting remote systems.
4. Activate the fixed kernel using the vendor-supported procedure.
5. Recheck the running kernel and application health.

After a conventional kernel update and reboot:

```bash
uname -r
```

Compare the result with the installed package and vendor advisory. Merely finding a patched kernel on disk does not prove it was booted.

For livepatch deployments, require explicit confirmation that the applied livepatch covers this CVE on the running kernel. An installed livepatch agent or active subscription is insufficient evidence.

## Can Firewall Rules Buy Time?

Red Hat publishes an interim nftables approach that filters IPv4 TCP packets containing IP options. Its [security bulletin](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016) warns that filtering can disrupt workloads and cannot replace patching.

**IPv4 options and TCP options are different fields.** A rule intended for the IPv4 header should not be replaced with an indiscriminate TCP-option block.

Before using a vendor rule, assess where packets travel. A host input chain and a container forwarding path are not interchangeable. Validate the rule against the deployment's routing, firewall manager, and rollback procedure.

Treat filtering as a temporary exposure reduction measure with an owner and removal plan. 

## Common Questions and Dangerous Assumptions

**Does upgrading Xray completely fix CVE-2026-98432?**

No. It changes application listener behavior. The kernel must also contain an active fix, and explicit MPTCP configuration deserves review.

**Does the absence of MPTCP connections prove safety?**

No. An idle listener may have no established connections. Connection snapshots also do not establish kernel patch status.

**Are IPv6-only services unaffected?**

The kernel announcement says the main IPv4 ownership issue does not affect the corresponding IPv6 path because options are duplicated. However, it also identifies a separate IPv6 request-migration issue involving CALIPSO. Verify actual IPv4 reachability, including dual-stack listeners, before drawing conclusions.

**Does HTTPS or an application login protect the server?**

Those controls operate after TCP connection establishment. They should not be treated as mitigation for this kernel processing defect.

**Does rebuilding a Docker image fix it?**

An application image rebuild does not replace the Linux kernel that runs the container. Include the underlying host or VM in the remediation scope.

**Does the research prove every Linux server can be rooted?**

No. The documented exploit uses an MPTCP listener. Broader vulnerability scope and demonstrated exploitation conditions should remain distinct.

**Does patching prove a previously exposed host was never compromised?**

No. Remediation and incident investigation answer different questions. If suspicious activity exists, preserve relevant evidence and follow the organization's incident-response process.

## Conclusion

CVE-2026-98432 requires coordinated application and operating-system maintenance. Xray's emergency release reduces default MPTCP exposure, while the lasting fix belongs in the running Linux kernel.

**Start with the public-facing hosts: inventory their kernels and listeners, apply appropriate temporary mitigations, install vendor-confirmed patches, and verify activation.** Close the maintenance task only when the running system—not merely its downloaded packages—has the fix.