Is Your Linux Server Affected by CVE-2026-98432? Check the Evidence

Key Takeaways

• Check the kernel actually running, then match its build to the correct vendor advisory. An installed update alone does not establish protection.
• Track vulnerability status and network exposure separately. A firewall can reduce reachability without fixing the kernel.
• Disabling MPTCP does not establish that CVE-2026-98432 is fixed. The published issue also involves IPv4 TCP request handling.
• Use distribution package versions, including their revisions and kernel variants. Upstream version comparisons can misclassify backported fixes.
• Check container hosts and Kubernetes nodes. Updating application images does not replace the kernel they share.
• Keep uncertain results explicit. Missing tools, incomplete advisories and custom kernels require verification, not an automatic safe verdict.

Last checked: October 30, 2026. This guide addresses CVE-2026-98432, the Linux networking vulnerability discussed in the Linux and Ubuntu repair guide. Distribution status can change after this date.

To check whether a Linux server is affected, collect its operating system identity and running kernel build, identify the corresponding kernel package, and compare it with the vendor's CVE record. Then verify whether a fixed build or CVE-specific livepatch is active. Assess reachable services separately.

What Does Affected Actually Mean?

Three questions need different evidence:

A server can be vulnerable while access is restricted. A patched server can still require investigation for activity that occurred before remediation.

Use the following classifications for the kernel assessment:

Keep a second field for exposure: reachable, restricted, or unknown. This prevents a network configuration change from being recorded as a kernel repair.

Why an MPTCP Check Alone Is Insufficient

The Linux kernel CVE announcement describes a race involving IPv4 socket options. One execution path can free options while another still reads them. It also identifies a related request socket migration path. The correction defers freeing the relevant objects until an RCU grace period has passed.

Anthropic's research reports remote root command execution against a Linux server with an MPTCP listener. That establishes a demonstrated configuration; it does not establish that every Linux TCP service is equally exploitable. Conversely, the broader kernel description means an absent MPTCP listener cannot clear an unpatched kernel.

Operational implication: establish patch status first. Use MPTCP and TCP configuration to prioritize exposure review, not to replace package verification.

Step 1: Identify the Operating System and Running Kernel

Run these commands on the server or VM whose kernel serves the workload:

date -u +%Y-%m-%dT%H:%M:%SZ
cat /etc/os-release
uname -r
uname -v
uname -m

Record the distribution ID, release, kernel release string, build information and architecture. Retain suffixes such as -generic, -aws, -azure and distribution package revisions.

On Ubuntu, capture the additional build signature when available:

if [ -r /proc/version_signature ]; then
  cat /proc/version_signature
fi

Canonical documents this interface on its Ubuntu kernel page. It helps distinguish Ubuntu builds beyond the shorter release string.

If the shell might be inside a container, use the following optional check:

systemd-detect-virt --container

A detected container is a reason to move kernel package verification to its host. A missing command or failed detection does not conclusively establish that the shell is on the host.

Important edge case: inside a container, /etc/os-release generally identifies the image's user space, while uname reports the kernel provided by its execution environment. Combining those two outputs can incorrectly associate a Debian container with an Amazon Linux host kernel. Ordinary Linux containers share their host kernel, as explained in Docker's container documentation.

Step 2: Identify the Kernel Package and Its Provenance

Ubuntu and Debian

Query the package associated with the running kernel release:

kernel_release=$(uname -r)
dpkg-query -S "/boot/vmlinuz-$kernel_release"
dpkg-query -W -f='${binary:Package}\t${Version}\t${source:Package}\t${source:Version}\n' "linux-image-$kernel_release"

The output distinguishes the binary package version from its source package and source version. These fields are documented in the dpkg-query manual.

If the image package uses a different name, query the owner returned by the first command. If nothing owns the path, investigate a custom kernel, a removed package, an unusual boot layout or execution inside a container.

Signed kernel images may come from a signing wrapper source package. Map that wrapper to the actual kernel source through vendor package metadata. On Ubuntu, the corresponding installed linux-modules package can provide another useful source-package reference:

dpkg-query -W -f='${binary:Package}\t${Version}\t${source:Package}\t${source:Version}\n' "linux-modules-$(uname -r)"

This package is not present in every kernel layout. A lookup failure remains an inventory gap.

RHEL and Amazon Linux

On conventional RPM-based kernel installations, query the owner of the kernel image:

rpm -qf "/boot/vmlinuz-$(uname -r)" --qf '%{NAME}\t%{EPOCHNUM}:%{VERSION}-%{RELEASE}\t%{ARCH}\t%{SOURCERPM}\n'

The RPM documentation describes file-owner queries and package metadata. Retain the package name, epoch, version, release and architecture when matching an advisory.

Package databases describe files installed on disk. They do not independently prove which binary was loaded at boot. Keep the running build information from Step 1 and complete the runtime checks in Step 4.

Step 3: Match the Exact Vendor Advisory

A distribution can backport a fix without adopting the upstream release number containing it. Red Hat's backporting guidance explains why version-only vulnerability detection can produce incorrect results.

Compare the same distribution, release, source package, kernel branch and supported product stream. Do not compare an Ubuntu ABI number with a Debian source package version, or a vendor kernel directly with an upstream cutoff.

Selected vendor status checked October 30, 2026:

The Ubuntu rows come from Canonical's CVE tracker; Debian's thresholds come from the Debian Security Tracker. Ubuntu cloud, HWE, OEM and real-time kernels have separate entries; the linux row is not a verdict for all variants. A version displayed alongside work in progress is not confirmation that the fix has shipped.

Use the Amazon Linux CVE record for branch-specific advisories and Red Hat's CVE record for its product assessment. A fix in an Amazon Linux kernel6.12 package does not establish protection for a machine running a different kernel package.

For automated comparisons, use Debian's package-version comparison semantics or RPM's epoch/version/release semantics. Plain string comparison, semantic-version libraries and sort -V are not substitutes for the package manager's rules.

Check repository visibility without installing updates

On systems using the documented DNF interface:

dnf --refresh updateinfo info --all --cves=CVE-2026-98432

This requests advisory information and may refresh the local metadata cache; it does not install packages. Confirm support with the local DNF help if the command is rejected. An empty result can reflect missing advisory metadata, disabled repositories or unavailable fixes. It is not a clean bill of health. The DNF command reference documents CVE filtering and update information.

Amazon Linux 2023 adds another important check:

dnf check-release-update

AL2023 uses versioned repositories. A host can be fully updated within an older repository release while a security update exists in a newer release. Review the target release and advisory before changing the repository selection.

Step 4: Verify That the Fix Is Active

Distinguish these three states:

1. Available: the repository offers a fixed package.
2. Installed: the fixed package is present on disk.
3. Active: the running kernel incorporates the fix.

Only the third state establishes runtime remediation.

After installing the vendor-supported update and completing the planned reboot or node replacement, repeat:

uname -r
uname -v
if [ -r /proc/version_signature ]; then
  cat /proc/version_signature
fi

Then repeat the package-to-advisory match. Check for bootloader fallback if the old kernel remains active. Red Hat's kernel update documentation explicitly includes rebooting after the package update.

Advanced pitfall: an unchanged release string. A package can be replaced or rebuilt without giving administrators a sufficiently distinct uname -r value. A package lookup performed afterward can describe newer files than the running binary. Use vendor build metadata and deployment or boot records to establish that the intended build was actually loaded.

If Livepatch is enabled

On Ubuntu systems with the client installed:

sudo canonical-livepatch status --verbose

Require evidence that the running kernel is supported, the applicable patch is successfully applied, and its published coverage explicitly includes CVE-2026-98432. An enabled subscription, successful check-in or generic healthy status is insufficient.

Canonical's Livepatch management documentation explains that the service can be enabled on an unsupported kernel without delivering patches. Livepatch availability for this particular CVE must be verified separately. An unchanged uname -r also does not disprove a successfully applied livepatch.

Step 5: Check TCP and MPTCP Exposure

These commands inspect configuration and sockets in the current network namespace:

sysctl net.mptcp.enabled
sysctl net.ipv4.tcp_migrate_req
sudo ss -lntp
sudo ss -M -lnp

Read the results carefully:

The kernel MPTCP documentation defines enabled as a per-namespace control over socket creation. The TCP sysctl documentation also describes migration policies involving BPF. The ss manual documents -M for MPTCP sockets. Older tooling or missing kernel diagnostic support can limit visibility.

Review network namespaces

On a host with the relevant util-linux tools:

sudo lsns -t net -o NS,PID,COMMAND

For each relevant namespace, select a representative process from the inventory. Replace the example PID before running:

namespace_pid=12345
sudo nsenter --target "$namespace_pid" --net ss -lntp
sudo nsenter --target "$namespace_pid" --net ss -M -lnp
sudo nsenter --target "$namespace_pid" --net sysctl net.mptcp.enabled
sudo nsenter --target "$namespace_pid" --net sysctl net.ipv4.tcp_migrate_req

lsns and nsenter support namespace inspection. Reconcile their output with the container runtime's inventory; permissions and process visibility can make an inventory incomplete.

Establish actual reachability

For each listener, inspect its bind address, host firewall, cloud security groups, load balancer path and access from untrusted internal networks.

A wildcard bind does not automatically mean internet exposure. A private address does not automatically exclude access from a compromised peer or VPN client. Where permitted, an ordinary connection check from the relevant network can confirm connectivity; it cannot prove or disprove this CVE.

Application authentication is not the deciding control for a flaw in TCP connection processing. Evaluate where traffic is blocked before reaching the relevant kernel path. Treat restricted access as mitigation while the patch assessment remains unchanged.

Step 6: Check Docker Hosts, Kubernetes Nodes and Cloud Images

For ordinary Docker workloads, perform package and build checks on the Linux host. Restarting containers or rebuilding an application image does not replace that host kernel.

For Kubernetes, collect a first-pass node inventory:

kubectl get nodes -o custom-columns='NAME:.metadata.name,OS:.status.nodeInfo.osImage,KERNEL:.status.nodeInfo.kernelVersion'

The Kubernetes Node API exposes OS and kernel information. Use it to identify nodes needing follow-up; it does not include a complete vendor package assessment or establish livepatch coverage.

Then complete four checks:

1. Identify the node OS and kernel package. An Ubuntu VM on AWS follows Ubuntu's package assessment; its location does not make it Amazon Linux.
2. Verify every node pool. One updated pool does not establish protection for the rest of the cluster.
3. Update future machine sources. Review launch templates, machine images and node pool configurations so replacements do not reintroduce an affected build.
4. Verify replacement nodes after rollout. Confirm the running build and application health, respecting disruption budgets and available capacity.

For provider-managed environments without host access, request an advisory or image-level remediation statement covering the relevant service and rollout. Record needs verification while that evidence is missing. Specialized sandbox and microVM runtimes require their own kernel ownership assessment.

Record a Result That Another Administrator Can Verify

A useful assessment preserves evidence rather than just a green or red badge. The following is a template, not a finding about any real server:

cve: CVE-2026-98432
checked_at_utc: REPLACE_WITH_TIMESTAMP
asset_id: REPLACE_WITH_INTERNAL_ASSET_ID
os_release: REPLACE_WITH_OS_AND_VERSION
running_kernel_release: REPLACE_WITH_UNAME_R
running_kernel_build: REPLACE_WITH_BUILD_SIGNATURE
kernel_package: REPLACE_WITH_PACKAGE_AND_REVISION
vendor_advisory: REPLACE_WITH_ADVISORY_URL
vendor_status_checked_at: REPLACE_WITH_TIMESTAMP
active_fix_evidence: not-yet-established
vulnerability_status: needs-verification
network_exposure: unknown
namespace_coverage: incomplete
next_action: complete-package-and-runtime-verification

Apply these decision rules:

• Fixed package installed, old affected kernel running: vulnerable unless an applicable livepatch is confirmed active.
• Fixed build verified running: patched for this CVE; retain the supporting advisory.
• Affected build with restricted network access: vulnerable, exposure restricted.
• Custom build without patch provenance: needs verification.
• Lookup failure or unavailable advisory data: needs verification; do not convert an error into not affected.

For a custom kernel, require the build owner to identify the relevant fixes or equivalent backports, associate them with the built artifact, and establish that artifact is running. An arbitrary version suffix cannot provide that chain of evidence.

Common Questions

Does disabling MPTCP completely fix CVE-2026-98432?

No. It changes MPTCP socket creation in the selected namespace; it does not replace vulnerable kernel code. Evaluate existing listeners, other namespaces and the broader TCP paths before describing exposure as reduced.

Can a server be vulnerable even when its package manager reports no updates?

Yes. The vendor may not have released a fix for that package track, repositories may be stale or restricted, or the server may be pinned to an older repository snapshot. It may also have a newer kernel installed while still running an older one.

Is a newer upstream kernel number always safer?

No. Distribution backports and product-specific changes make that comparison unreliable. Match the vendor's package and build assessment.

Does an IPv6 listener mean the server is unaffected?

No automatic conclusion follows. The kernel announcement distinguishes the primary IPv4 issue from a separate IPv6 migration concern. Assess actual protocol handling and the vendor's build status instead of using a listener's address family as a patch verdict.

Can a remote scanner establish that the fix is active?

A network-only check usually lacks the package, build and livepatch evidence required here. Authenticated inventory can collect that evidence, but the assessment must still account for backports and the running kernel.

Does a clean kernel log prove that exploitation did not happen?

No. Anthropic reported that failed attempts in its demonstrated exploit could leave the system running, allowing retries. The absence of a crash is not evidence of patching or a clean incident history. A laboratory demonstration also does not establish that a particular server was attacked.

Should administrators run an exploit to test production servers?

Package provenance, vendor advisories and active-build verification provide the appropriate basis for this assessment. Exploit testing can disrupt a system and is unnecessary for determining whether the vendor's fix is running.

Conclusion

To check whether a Linux server is affected by CVE-2026-98432, establish which kernel build is running, what the vendor says about that exact build, and whether the fix is active. Record network exposure separately.

Start with the inventory commands, follow the appropriate distribution advisory, and preserve the evidence for each verdict. For affected systems, deploy the supported fix, verify the running build after rollout, and update the images that will create tomorrow's servers. Use the Linux and Ubuntu remediation guide to continue from assessment to repair.