CVE-2026-99999 Guest-to-Host Escape: mitigation and kernel update for CloudLinux

📋 TL;DR — last updated November 5, 2026, 10:25 UTC

CVE-2026-99999 (CVSS 9.3 Critical) is a flaw in how the Linux kernel handles IPv4 checksum metadata from virtio-net. An untrusted virtual machine (VM) guest can overwrite two bytes of an already-validated IPv4 header on the host. The researcher reports a host memory leak, a host crash, and code execution as root on a test host. No public proof-of-concept exists, and we have not reproduced the attack.

• Affected: every supported CloudLinux kernel line carries the vulnerable code. Hosts that run untrusted VM guests are exposed on every version. Shared hosts without VMs are exposed only where unprivileged users can create user namespaces.
• Fix status: fixed kernels and KernelCare livepatches are available for every CloudLinux version except CloudLinux 7. Install one or the other now.
• — Stream 1, CloudLinux kernel (CloudLinux 7h, 8): fixed kernel in the stable channel, 4.18.0-553.177.1.lve or newer.
• — Stream 2, AlmaLinux kernel (CloudLinux 9, 10): fixed kernels in the stable channel, 5.14.0-687.59.1.el9_8 and 6.12.0-211.67.1.el10_2 or newer.
• — Stream 3, TuxCare ELS kernel (CloudLinux 8 LTS, 9 LTS): fixed kernel-lts els17 in the stable channel.
• — Stream 4, KernelCare livepatch: on the main feed for CloudLinux 7h, 8, 9, 9 LTS, 10 and CloudLinux for Ubuntu 22.04. Still in preparation for CloudLinux 7.
• — CloudLinux 7: no fixed kernel and no livepatch yet. Use the mitigation below.
• — CloudLinux for Ubuntu 22.04: the fixed Ubuntu kernel is still pending from Canonical; the livepatch covers the gap.
• Mitigation: partial and untested. Turn off checksum offload for untrusted guests, and disable unprivileged user namespaces to close the local path. Only needed where neither the fixed kernel nor the livepatch is in place.
• Verify: uname -r against the target version, or kcarectl --patch-info | grep CVE-2026-99999.
• Status page: PwnEscape (CVE-2026-99999) on the CloudLinux status page.

CVE-2026-99999 lets an untrusted guest on a virtualization host corrupt the host’s network stack with crafted checksum offload metadata. Kernel.org reported it. The CVE record describes the VM-guest case. The same code is reachable by other routes on some configurations, covered below.

The bug dates to Linux v2.6.27, so every CloudLinux kernel line carries it.

Why it matters

If you run VPS hosting, the “guest” is your customer. Anyone who rents a VM can send the crafted metadata, and the host’s virtual machine monitor (VMM, such as QEMU) already forwards it. No host device access and no user namespace is needed. User namespace settings do not protect against this path.

On shared hosting without VMs, the question is whether a tenant can create an unprivileged user and network namespace. We consider that path plausible from the code, and we have not confirmed it.

Affected CloudLinux versions

† CloudLinux for Ubuntu 22.04 runs the stock Ubuntu kernel. The fix arrives from Canonical through apt, with no CloudLinux kernel stream.

KernelCare delivers the fix as a livepatch, without a reboot. It is on the main feed for every version in the table except CloudLinux 7, where it is still in preparation. CloudLinux 8 LTS takes the fix as a kernel upgrade.

On servers licensed through CloudLinux Network (CLN) the livepatch applies automatically.

Am I exposed?

Exposure depends on how a server is used, not on its kernel version.

• The host runs untrusted VM guests. It is exposed regardless of its user namespace settings, until it is patched or checksum offload is turned off for those guests.
• Shared hosting without VMs. The local path needs an unprivileged user who can create a user and network namespace. Run sysctl user.max_user_namespaces: a value of 0 means tenants cannot create one. To confirm, run unshare -Urn as an unprivileged user. If it fails, the local path is closed.

Unprivileged user namespaces are on by default on CloudLinux 8 and later, so do not assume a CloudLinux 10 server has them off. In our tests on CloudLinux 7h, 8, 8 LTS, 9 and 9 LTS, the local path produced no kernel oops and no Kernel Address Sanitizer (KASAN) report, so we have not confirmed that it is exploitable.

Is there a mitigation?

Partial workarounds exist. None has been tested against this bug yet, and each removes one prerequisite. The fixed kernel or the KernelCare livepatch is the remedy. In order of preference:

1. Update to the fixed kernel for your delivery stream. A reboot is required.
2. Apply the KernelCare livepatch for your kernel. No reboot is required.
3. On hosts that run untrusted VM guests, stop offering checksum offload to them.
4. Against the local path, disable unprivileged user namespaces.

Stop offering checksum offload to untrusted guests

QEMU:

-device virtio-net-pci,netdev=n0,csum=off,guest_csum=off

libvirt: inside the element.

Compatibility: this is set per VM and needs a guest restart. It lowers guest network throughput because the guest loses TCP segmentation offload (TSO) and generic segmentation offload (GSO).

Disable unprivileged user namespaces (local path only, no effect on VM guests)

sysctl -w user.max_user_namespaces=0
echo "user.max_user_namespaces = 0" > /etc/sysctl.d/90-no-userns.conf

Compatibility: this breaks rootless containers and the Chrome and Flatpak sandboxes. To revert, delete the file and set the previous value back.

CageFS, CloudLinux’s virtualized filesystem that isolates each hosting account, does not close this.

Update instructions

Stream 1: CloudLinux kernel (CloudLinux 7h, 8)

Update: November 5, 2026, 10:25 UTC.

The fixed CloudLinux 7h and CloudLinux 8 kernels are in the stable channel. Target versions: kernel-4.18.0-553.177.1.lve.el7h and kernel-4.18.0-553.177.1.lve.el8, or newer. To install:

yum update kernel
reboot

Status: The fixed kernel is not yet available. CloudLinux rebuilds the kernel once the upstream fix lands. The target version will be added here on release.

Once the build reaches the testing channel:

# CloudLinux 8
yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
reboot
# CloudLinux 7h
yum update 'kernel*' --enablerepo=cl7h_beta
reboot

After promotion to the stable channel, yum update kernel; reboot is enough.

Stream 2: AlmaLinux kernel (CloudLinux 9, 10)

Update: November 5, 2026, 10:25 UTC.

AlmaLinux has shipped the fix, and the fixed kernels are in the stable channel for CloudLinux 9 and CloudLinux 10. Target versions: kernel-5.14.0-687.59.1.el9_8 (CloudLinux 9) and kernel-6.12.0-211.67.1.el10_2 (CloudLinux 10), or newer. No testing repository is needed. To install:

dnf update kernel
reboot

Status: The fixed kernel is not yet available. CloudLinux 9 and 10 take the AlmaLinux kernel, so the fix arrives when AlmaLinux ships it. The target version will be added here on release.

Once the kernel reaches the AlmaLinux testing repository, install the testing release package from the AlmaLinux repo URL, update, reboot, then disable the testing repository:

# CloudLinux 10
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-<ver>.el10.x86_64.rpm
dnf update 'kernel*'
reboot
dnf config-manager --disable almalinux-testing

CloudLinux 9 follows the same steps with the el9 package. Once the kernel reaches the production repositories, dnf update kernel; reboot is enough.

Stream 3: TuxCare ELS kernel (CloudLinux 8 LTS, 9 LTS)

Update: November 5, 2026, 10:25 UTC.

The fixed TuxCare ELS kernel is in the stable channel for CloudLinux 8 LTS and CloudLinux 9 LTS. Target versions: kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els17 (CloudLinux 8 LTS) and kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els17 (CloudLinux 9 LTS), or newer. A regular kernel update installs it, and a reboot starts the fixed kernel.

Status: The fixed kernel is not yet available. CloudLinux 8 LTS and 9 LTS receive kernels through TuxCare Endless Lifecycle Support (ELS), which backports fixes independently.

ELS-subscribed servers install kernel-lts from the ELS repository.

Stream 4: KernelCare livepatch (all affected versions)

Update: November 5, 2026, 10:25 UTC.

The KernelCare livepatch for CVE-2026-99999 is on the main feed for every CloudLinux version except CloudLinux 7: CloudLinux 9 since October 16 (K20261016_0002), CloudLinux 10 since October 19 (K20261017_0012), CloudLinux 7h and CloudLinux 8 since October 21 (K20261021_0007 and K20261021_0006), CloudLinux 9 LTS since October 22 (K20261021_0035 and K20261021_0036), and CloudLinux for Ubuntu 22.04 with the 5.15 kernel since November 3 (K20261031_0019).

A subscribed server takes it on its next update cycle, or on demand:

kcarectl --update

The CloudLinux 7 livepatch is still in preparation. Until it ships, use the mitigation on CloudLinux 7. CloudLinux 8 LTS gets no livepatch for this issue and takes the fix as a kernel upgrade (Stream 3).

Status: KernelCare livepatch is currently available in the test feed for the EL9 family and will be released to the main feed later today.

• K20261016_0001: RHEL 9 — in testing
• K20261016_0002: AlmaLinux 9 and CloudLinux 9 — currently in the main feed
• K20261016_0004: Oracle Linux 9 — in testing
• K20261016_0005 / K20261016_0006: Rocky Linux 9 — in testing

Patches for el8 and el10 are in progress.

When a livepatch is published, pull it from the testing feed first, then from the main feed:

kcarectl --update --prefix test
kcarectl --update

How to verify you are patched

Kernel streams: compare uname -r with the target version in the most recent update callout for your stream.

KernelCare: run:

kcarectl --patch-info | grep CVE-2026-99999

Use --patch-info, not --info: kcarectl --info | grep CVE-2026-99999 returns nothing even on a patched server.

Why this matters on a hosting platform

On a VPS or virtual machine host, the attack starts with a customer. A guest sends crafted virtio-net checksum metadata, the host forwards it into its IPv4 stack, and the flaw lets the guest leak host heap memory and crash the host. The researcher also reports code execution as root on a test host. That chain is not public, and we have not verified it.

If it holds, root on the host puts every other guest on that machine within reach, and patching removes that step from an attacker’s plan.

On shared hosting, the local path matters only where tenants can create user namespaces. The attacker there is whoever compromised one of the sites you host, not a customer you trust. They would create an unprivileged user and network namespace, which grants the capability to create a TAP device (a virtual network interface) with the virtio-net header enabled, and then feed the crafted value into the stack. This is plausible from the code. We have not confirmed it.

Technical details of CVE-2026-99999

virtio-net is the paravirtualized network device that virtual machines use. With checksum offload, the guest hands the host a packet whose checksum is unfinished, along with a header field, csum_start, that says where the checksum begins.

The attacker sets csum_start to point inside the IPv4 header. The packet reaches the host’s IPv4 stack, where ip_do_fragment() calls skb_checksum_help(). That function writes two attacker-controlled bytes into the IPv4 header, which the kernel had already validated. The write stays inside the packet buffer.

The kernel then re-reads the header length (ihl) and copies that many bytes of header into every fragment. Up to 40 bytes of nearby host heap memory leak back to the sender per fragment.

Four routes feed the same offload metadata:

• An untrusted VM guest through TAP or vhost-net (the in-kernel virtio-net backend). This is the case in the CVE record, and the VMM forwards the guest’s offload header.
• An unprivileged local user through tun with IFF_VNET_HDR, inside a user namespace. Plausible from the code, not confirmed in our tests.
• An AF_PACKET socket with PACKET_VNET_HDR. It needs CAP_NET_RAW, which is also available inside a user namespace.
• The owner of a macvtap or ipvtap device.

No public proof-of-concept exists, so we have not reproduced the attack. The host memory leak, the crash, and the root code execution come from the researcher’s test host.