CVE-2026-45850

What it actually does

This flaw is in the Linux kernel IPVS IPv6 checksum-handling path. When IPv6 packets contain extension headers before the transport protocol header, IPVS can validate the checksum using the wrong offset because the packet length/offset accounting is mishandled. In affected kernels, a low-privileged local attacker who can reach or influence the vulnerable IPVS code path may trigger incorrect checksum validation and cause a denial-of-service condition affecting system availability. There is no known confidentiality or integrity impact, and the vulnerability is not currently listed in CISA KEV.

Why it matters to the business

Systems using the Linux kernel with IPVS enabled may be susceptible to service disruption or host instability if the vulnerable code path is triggered. The primary operational risk is downtime for workloads that rely on Linux-based load balancing, container networking, Kubernetes service proxying modes that use IPVS, or other IPVS-backed network services. The CVSS score is medium, EPSS is currently very low, and there is no public exploit maturity or KEV listing, so this should be prioritized as routine-to-expedited maintenance rather than an emergency unless IPVS is heavily used in availability-critical infrastructure.

How an attack unfolds

An attacker first needs local low-privileged access or another permitted local execution context capable of generating traffic or network conditions that exercise the kernel IPVS IPv6 packet-processing path. The attacker then crafts or causes IPv6 traffic that includes extension headers before the transport protocol header. On a vulnerable kernel with IPVS active, the checksum validation logic may use an incorrect header position, mishandling the packet and triggering a denial-of-service condition. Successful exploitation would be expected to manifest as service interruption, kernel instability, or a crash rather than data theft or privilege escalation. No ransomware use, named threat actor activity, or mature public exploit is currently indicated for this CVE.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the upstream IPVS fix for IPv6 extension-header checksum handling, specifically the change described as skipping IPv6 extension headers for checksum checks in IPVS. Because no exact fixed versions were provided, use distribution advisories from the operating system vendor and apply the latest stable kernel security update for each affected platform. Where immediate patching is not possible, reduce exposure by disabling IPVS if it is not required, avoiding IPVS-based Kubernetes or load-balancing modes where alternatives are available, restricting untrusted local access, limiting the ability of untrusted users or containers to create raw or crafted IPv6 traffic, and filtering or disabling IPv6 extension headers where operationally safe. Reboot systems after kernel updates unless live patching from the vendor is confirmed to include the relevant fix.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed release and that the applied changelog includes the IPVS IPv6 extension-header checksum fix. Validate that systems have actually booted into the patched kernel, not merely installed it. Check whether IPVS is enabled by reviewing loaded modules and configuration for ip_vs and related IPVS modules. For container and Kubernetes environments, verify whether kube-proxy or the platform networking stack is using IPVS mode. If mitigation rather than patching is used, confirm IPVS is disabled or IPv6 extension-header handling is restricted according to the approved network policy. After remediation, run service health checks for load-balanced IPv6 traffic and monitor kernel logs for crashes, warnings, or packet-processing errors.

Typical attack path

1. Identify a Linux system running an affected kernel where IPVS is enabled or reachable through local network functionality.
2. Obtain low-privileged local access or another local execution context capable of generating relevant IPv6 traffic.
3. Craft IPv6 packets containing extension headers before the transport protocol header.
4. Send the crafted traffic through the IPVS packet-processing path.
5. Trigger the checksum-validation defect, causing service disruption or host availability impact.

How to detect it

To assess possible prior exploitation, review kernel and system logs around periods of unexplained outages, reboots, node failures, or load-balancer instability. Relevant log sources include journald, syslog, kern.log, dmesg output, crash dumps, kdump/vmcore artifacts, hypervisor reset events, Kubernetes node events, kubelet logs, and load-balancer health telemetry. Look for kernel oopses, BUG or WARNING traces, soft lockups, panics, or sudden reboots involving IPVS, IPv6 packet processing, checksum handling, or ip_vs modules. In Kubernetes environments, correlate node NotReady events, pod evictions, kube-proxy IPVS mode, and IPv6 traffic spikes. Network telemetry may show unusual volumes of IPv6 packets with extension headers immediately before instability, but there are no known public exploit-specific packet signatures or attacker-specific indicators for this CVE. Because the expected impact is denial of service, absence of persistent artifacts does not rule out attempted exploitation.

What your security team should do

• Inventory Linux systems that use IPVS, including load balancers, container hosts, and Kubernetes nodes configured for IPVS mode.
• Prioritize patching availability-critical IPVS systems during the next maintenance window, with faster action for internet-facing or multi-tenant hosts where untrusted local execution is possible.
• Apply the latest vendor kernel security updates and reboot into the fixed kernel, or validate vendor live patches where used.
• If patching is delayed, disable IPVS where not required and restrict untrusted local users, containers, and workloads from generating crafted IPv6 traffic.
• Review Kubernetes and container networking configurations for IPVS use and plan upgrades through the platform’s supported node image or kernel update process.
• Monitor kernel logs and availability telemetry for unexplained crashes, soft lockups, packet-processing warnings, or IPVS-related instability.
• Track vendor advisories for exact fixed kernel versions because the input does not provide package-specific fixed releases.