CVE-2026-99999: Patch the Linux Host, Not Just the Panel

A newly disclosed Linux kernel vulnerability deserves the immediate attention of cloud providers, hosting companies, and businesses operating their own virtual server fleets.

CVE-2026-99999, also known as PwnEscape, affects IPv4 packet processing in the Linux kernel. Under the right conditions, an untrusted virtual machine can send specially prepared network data that corrupts memory in the host kernel. Researchers demonstrated that the flaw can cross the isolation boundary between a guest and its KVM host.

That is the important part. A customer or internal user who controls one virtual machine may be able to reach the computing node beneath it. For a platform designed around keeping workloads separate, this is not a maintenance item to leave until a convenient quarter.

The bug is below the control panel

Virtualization platforms have several layers. Proxmox VE, Virtualizor, SolusVM, and similar products help administrators create virtual machines, assign resources, manage networks, and provide a customer interface. KVM and QEMU handle important parts of virtualization. Beneath those layers, however, the Linux kernel still manages host memory, networking, and virtual network devices.

CVE-2026-99999 is in that Linux networking layer. It is not a flaw limited to one hosting panel and it is not caused by a careless Proxmox, Virtualizor, or SolusVM setting.

Changing the panel does not remove the vulnerable kernel. Hiding its web interface does not fix packet processing. Even a management system with perfect passwords and no public login page still depends on the host operating system underneath it.

This is why every Linux-based computing node running untrusted or customer-controlled virtual machines should be checked and upgraded, regardless of which hypervisor management system sits above it.

How a virtual machine can affect the host

Normally, a guest virtual machine sends network traffic through a virtual network device. The host kernel receives that traffic and performs part of the work required to deliver it. For performance, the guest can supply metadata describing where a packet checksum should be calculated.

The vulnerability allows malformed checksum metadata to reach the host IPv4 stack. The kernel may then write the checksum in the wrong place, corrupting a network header after other parts of the networking stack have already trusted it.

The full exploitation research is technical, but the possible results are easy to understand:

• disclosure of host memory;
• a crash of the computing node;
• execution of code on the host;
• escape from an untrusted guest into the virtualization server.

The original PwnEscape research demonstrated a guest-to-host escape in KVM environments. Red Hat likewise describes the risk as potentially allowing arbitrary code execution, denial of service, or disclosure of sensitive host memory.

The upstream Linux announcement rates the issue as Critical with a CVSS score of 9.3. The vulnerable code dates back many years and appears across numerous kernel branches, so this is relevant to long-running clusters as well as recently deployed ones.

Do not judge exposure by the kernel version alone

The upstream fix has been applied to several maintained kernel branches, including 5.10, 5.15, 6.1, 6.6, 6.12, 6.18, and newer releases. That list is useful to kernel developers, but it is not a safe upgrade checklist for every server administrator.

Linux distributions frequently backport security fixes without changing to the latest upstream kernel version. A patched distribution kernel may therefore have a version number that looks older than the upstream fixed release. Conversely, a familiar package name does not prove that the fix is installed and active.

Check the security bulletin and package status published by the vendor that supplies your host kernel. Depending on the deployment, that may be Debian, Ubuntu, Red Hat, AlmaLinux, Rocky Linux, CloudLinux, Proxmox, or another platform vendor. Follow the package version specified by that vendor rather than comparing only the output of uname -r with an upstream list.

The following official pages are useful starting points for checking current status and package information:

• AlmaLinux: PwnEscape patched kernels lists affected AlmaLinux releases and the corrected kernel builds. At publication time, the builds were available from the testing repository, so check the page for promotion to production before choosing an update channel.
• CentOS Stream: official CVE handling policy explains how security fixes enter CentOS Stream. CentOS Stream does not publish a separate advisory for every CVE, so also follow the Red Hat CVE-2026-99999 status page and verify the actual CentOS kernel package available to your stream.
• The Debian CVE tracker provides release-specific status, while DSA-6568-1 identifies the corrected kernel for Debian 13, or trixie.
• Ubuntu’s CVE-2026-99999 tracker shows the evaluation and update status for each supported Ubuntu release and kernel flavour.
• Proxmox’s CVE-2026-99999 response states that the fix is included in the supported proxmox-kernel-7.0.14-24-pve package series.

These pages can change as packages move from testing to stable repositories. Check them again immediately before maintenance. End-of-life kernels and platform releases may not receive an update at all, in which case migration to a supported release is part of the fix.

Installing a kernel is only half the update

A new kernel package sitting on disk does not protect a host that is still running the previous kernel. In most environments, the computing node must be rebooted unless the vendor explicitly confirms that an applicable live patch is installed.

For a production virtualization cluster, a sensible process includes:

1. Read the operating system and virtualization vendor bulletins.
2. Confirm which host kernel package contains the fix.
3. Check cluster health, backups, replication, and available capacity.
4. Migrate or safely stop guest workloads according to the platform design.
5. Install the security updates and reboot the computing node.
6. Verify the running kernel after boot, not only the installed package.
7. Return workloads gradually and monitor networking, storage, and node health.
8. Repeat the process across every node, including spare, staging, and rarely used systems.

Do not forget powered-off or standby nodes. A forgotten host can rejoin the cluster months later with an old kernel and an impressive uptime value that nobody should celebrate.

ITLDC computing-node upgrades are in progress

ITLDC is currently upgrading its virtualization clusters to apply the security patches. The work covers HD VDS, NVMe VDS, and legacy VDS platforms.

According to our maintenance notice, the upgrade window runs from October 20 at 12:00 EEST until October 22 at 20:00 EEST. Each virtual server will be rebooted during the maintenance, with a brief interruption expected to last approximately five to seven minutes.

Dedicated server and colocation customers who host their own virtual machines control that underlying node themselves. They should schedule maintenance, apply the fixed host kernel supplied by their vendor, and complete the required reboot.

Check every virtualization vendor you depend on

Organizations often have more than one virtualization environment: production clusters, laboratory systems, customer platforms, build workers, temporary sandboxes, and an old node kept because one application “still needs it.” CVE-2026-99999 makes that inventory important.

Cloud providers should review every computing-node image and deployment channel. Corporate administrators should check private-cloud clusters and individual KVM hosts. Resellers and partners should verify what their infrastructure vendors are doing and whether a maintenance window has been announced.

The management product is not the deciding factor. If the computing node is Linux-based and runs virtual machines, check its kernel vendor’s bulletin and apply the update. This includes installations managed through Proxmox, Virtualizor, SolusVM, custom orchestration, or a collection of shell scripts that became a platform when nobody was looking.

CVE-2026-99999 is a useful reminder that virtualization security is the security of the entire stack. The panel matters, the hypervisor matters, and the host kernel matters. This time, the urgent update is at the bottom of that stack.