CVE-2026-98432: How to verify the fix is actually running

A critical Linux flaw, CVE-2026-98432, can let an attacker who reaches an affected server over the network take it over without a password. The Linux kernel CVE team assigns it 9.8 out of 10, placing it in the highest severity category, critical.

The flaw affects IPv4 TCP connection handling in the kernel, the operating system’s core, before application authentication. Anthropic demonstrated an attack against servers using Multipath TCP, a networking feature. A load balancer that terminates TCP connections can keep untrusted client connections off backend servers; a TCP passthrough load balancer can forward attack traffic. Check which kind you use and whether the server also accepts direct or internal connections. The usual fix is a vendor-patched kernel and a restart, or replacement with a patched machine. AWS’s security bulletin explains which services require customer action.

Why a clean container scan isn’t enough

Container scanners check the packages an application ships in. An ordinary Linux container has no kernel of its own; it borrows the one on the server it runs on. A scan can come back clean while that server stays exposed. Docker’s documentation explains how containers share the host kernel.

Clearing a finding for a kernel-related package inside a container still does not prove the host kernel is patched. A rebuild can turn that scan green while leaving the affected server unchanged.

To verify the fix, check the server running the container. Use a server vulnerability scanner or collect the running kernel’s version and build details, then compare them with the operating-system vendor’s advisory. After patching and restarting or replacing the machine, check again to confirm the fixed kernel is active. Include production servers and build machines: a scanner can only report on the machines it covers.

CVE-specific vendor advisories: Ubuntu · Red Hat · Debian · SUSE · Amazon Linux.

Find the configuration that keeps bringing the problem back

A machine image is the template used to launch a server. If infrastructure configuration keeps selecting an outdated image, replacing a vulnerable machine can create another vulnerable machine.

For a platform leader, the job is to make the fix stick across services and build pipelines, including teams with different workflows in the same CI system. Require approved, patched machine images, then verify that affected running machines have the fix active. The platform team should own coverage across those environments so a missing check cannot disappear into a green application report.

Maintain one central rule, using approved machine images and kernel builds that security updates as new flaws are disclosed. The approved versions need to follow each vendor’s advisory: vendors can apply fixes to older release lines, so one version number cannot serve as the minimum for every Linux system. Red Hat’s backporting guidance explains the distinction.

A configuration that selects the “newest image” still needs a check of the running machines. Existing servers can keep running an older kernel until they are updated or replaced. Keep unresolved image selections marked as unknown until there is enough evidence to check them.

Turn the requirement into a Lunar guardrail

Earthly Lunar is a guardrails engine. It connects to a company’s code repositories and build pipelines, keeps a structured inventory of how each service is built and configured for deployment, and checks that inventory deterministically against company rules. The platform team can introduce a rule centrally, first measuring the gap and later blocking merges or releases that fail it.

For this flaw, the proposed guardrail would use that inventory in three ways:

• Find where the kernel is chosen. Lunar’s Terraform collector already stores the parsed infrastructure configuration. A custom rule could check machine images selected for Kubernetes nodes, server launch templates, and individual servers against the approved versions. It would need to resolve each selection to a known image and patched kernel build; raw image IDs cannot be compared as version numbers. Packer and Karpenter paths would need collection coverage too.

• Check the self-hosted build machines. A custom check at the start of each self-hosted build job could record the running kernel, operating-system build, machine identity, and check time, then compare that evidence with the approved versions. An ordinary Linux container job still uses the host’s kernel. This would catch machines running an old kernel even when configuration selects the latest image.

• Prioritize services for investigation. The demonstrated attack needs a Multipath TCP listener, which Go enables by default on Linux starting with Go 1.24, subject to compatibility settings and overrides. Lunar’s Go collector records the version declared by the project, giving teams a starting list to investigate. Confirm the deployed service’s listener and network exposure before treating it as a match for the demonstrated attack. The Go Security Team warns that the underlying bug is not limited to Multipath TCP, so other affected hosts still need patching.

Verify the fix on running servers

Changing infrastructure configuration does not prove that a rollout has finished. Confirm that affected machines were patched or replaced and that the fix is active. Before signing off, record each machine’s owner, running kernel build, matching vendor fix, and verification time. Keep unchecked machines visible with an owner and a deadline. If an applicable vendor live patch is used, verify that patch is active; the kernel version alone will not show it.

The infrastructure rule would check what the code selects; the build-machine check would cover the hosts running CI jobs. Verifying production servers needs a separate, scheduled check against the cloud account or cluster, with permission to read the necessary host information. That would find machines still running an old kernel after configuration has changed. Existing infrastructure tools would apply the updates and restarts.

The Terraform and Go inventory described above already exists. The kernel-specific rule and build-machine collector are designs for custom checks, not a ready-made CVE-2026-98432 guardrail. They would need to be implemented and tested before enforcement, along with the separate collection needed to check live production servers.

Kernel patching is one example of a broader platform problem: applying an engineering standard consistently across services and teams. Earthly Lunar uses the same collection and enforcement approach for standards such as test coverage, approved dependencies, and on-call readiness, so each new requirement does not depend on another round of repository-by-repository reminders.