PwnEscape on OpenStack, oVirt and libvirt: patching KVM host fleets

PwnEscape (CVE-2026-99999) is a host kernel flaw, so on OpenStack, oVirt or plain libvirt clouds every compute host that runs untrusted guests needs a fixed kernel plus a reboot or live patch. Drain each host with live migration, patch it, verify the kernel it is actually running, put it back in service, and tell tenants what to expect.

Our PwnEscape explainer covers what the bug is, how the checksum trick works and why severity scores differ. This is the operator's version: how to patch tens or hundreds of KVM hosts behind a control plane without breaking tenant workloads.

What changed for fleet operators this week

The fix has been upstream for a week, but vendor kernels are arriving at very different speeds.

If your hosts run Ubuntu or RHEL, prepare the drain and verification work now so you can start the day a kernel ships. The upstream commit also calls itself defence in depth and says fuller input validation is coming, so plan for this cycle to happen twice.

Which hosts in your cloud are in scope

The vulnerable code sits in the networking stack of whichever kernel hosts a virtio-net guest. AWS describes affected systems as self-managed virtio-net KVM guests on hosts with unpatched kernels from 4.4 through 6.18, and VirtFusion names TAP and vhost-net networking. pwn.ai does not discuss vhost-user or OVS with DPDK, so do not assume a particular data path makes you safe.

Step 1: build the compute host inventory

You need one list of every host that runs guests, with its distribution, the kernel it booted and the kernel package on disk. Pull it from the control plane, which knows about hosts your spreadsheet forgot.

OpenStack:

# Every compute service, its host, state and status
openstack compute service list --service nova-compute

# Hypervisor view, including state
openstack hypervisor list

# Guests on one host (admin only)
openstack server list --all-projects --host COMPUTE_HOST

oVirt or RHV: take the host list per cluster from Compute, then Hosts, in the Administration Portal, and note which host runs the hosted engine VM.

Plain libvirt (or any of the above), gather kernels in one pass with your configuration tool:

# Running kernel on every host in the "kvm" group
ansible kvm -m command -a 'uname -r'

# Installed kernel packages (RHEL family, SUSE, Oracle, Amazon Linux)
ansible kvm -m shell -a 'rpm -q kernel kernel-default kernel-uek 2>/dev/null'

# Installed kernel packages (Debian, Ubuntu, Proxmox)
ansible kvm -m shell -a "dpkg -l 'linux-image-*' 'proxmox-kernel-*' 2>/dev/null | grep '^ii'"

# Guests per host
ansible kvm -m command -a 'virsh list --all'

Save the output with a date. You will diff against it in Step 6.

Step 2: check per-distro kernel status (as of 21 October)

We checked each vendor's tracker on 21 October; recheck before each window. Compare against the vendor's package version, not the upstream number, because, as TuxCare warns, enterprise kernels backport fixes without changing their version string.

If you build your own host kernels, kernel.org listed 7.2.12, 6.18.58, 6.12.114 and 6.6.160 (21 October) and 6.1.190, 5.15.223 and 5.10.272 (15 October); Warp2Search reports the four newest all carry the fix.

Two oddities: Red Hat's CVE page says it "tracks this flaw as a KEV active-exploit case", but our explainer found no CISA KEV listing. And SUSE lists a Liberty Linux 10 build tied to RHSA-2026:85321, whose Red Hat text did not mention this CVE when we checked. Treat RHEL 10 as unfixed until Red Hat says otherwise.

Step 3: understand your live patch options

A live patch fixes the running kernel without a reboot, so guests never move. Each service decides which CVEs and kernels it covers. These are the facts we could confirm on 21 October, in no particular order.

Even with a live patch, install the vendor kernel when it ships so the next boot is fixed too.

Step 4: drain, patch and return each host

The pattern is the same everywhere: stop scheduling to the host, move its guests to an already patched host, patch and reboot, verify, then return it. Patch one spare host first so the first migrations land somewhere safe.

OpenStack nova

1. Stop scheduling to the host.

openstack compute service set --disable \
  --disable-reason "PwnEscape kernel patch" COMPUTE_HOST nova-compute

2. List the guests that must move.

openstack server list --all-projects --host COMPUTE_HOST -c ID -c Name -c Status

3. Live migrate them. One at a time with the unified client:

openstack server migrate --live-migration --wait SERVER_ID
# or choose a patched destination yourself
openstack server migrate --live-migration --host PATCHED_HOST --wait SERVER_ID
# guests on local disk need block migration
openstack server migrate --live-migration --block-migration --wait SERVER_ID

The deprecated nova client can drain a whole host, capping concurrent migrations:

nova host-evacuate-live --max-servers 2 COMPUTE_HOST

4. Watch progress. openstack server show SERVER_ID reports MIGRATING, and its host field shows where the guest ended up. A guest still on the source host means the migration failed; the nova docs point to scheduler, conductor and source compute logs. Cancel a stuck one with openstack server migration abort SERVER_ID MIGRATION_ID.
5. Handle the leftovers. Guests that will not move (see Step 5) get a cold stop and start agreed with their owners.
6. Patch and reboot the empty host, then confirm the running kernel (Step 6).
7. Return it to service.

openstack compute service set --enable COMPUTE_HOST nova-compute
openstack compute service list --service nova-compute

Do not use nova evacuate or host-evacuate here. The nova docs describe evacuation as recovery from a failed host that rebuilds instances, not to be used while they are running.

oVirt and RHV

The engine does the drain work. Per the oVirt Administration Guide:

1. Single host: Compute, Hosts, select the host, Installation, Check for Upgrade, then Installation, Upgrade. VMs migrate per their migration policy; you are prompted to shut down any VM with migration disabled. The host moves through Maintenance, Installing, Reboot and Up.
2. Manual control: Management, Maintenance moves running VMs to other hosts. Pinned VMs that cannot migrate are shut down, so check the Pinned to Host filter on the host's Virtual Machines tab first.
3. Whole cluster: Compute, Clusters, Upgrade. Stop Pinned VMs, Reboot After Upgrade and Use Maintenance Policy are on by default; the timeout defaults to 60 minutes.

Patch the hosted engine's host last and follow your release's hosted engine procedure.

Plain libvirt and QEMU

# Move one running guest and keep its definition only on the destination
virsh migrate --live --persistent --undefinesource --verbose \
  GUEST qemu+ssh://PATCHED_HOST/system

# Guests on local, non-shared disks
virsh migrate --live --persistent --undefinesource --copy-storage-all --verbose \
  GUEST qemu+ssh://PATCHED_HOST/system

# Progress of a running migration
virsh domjobinfo GUEST

When virsh list --all on the source shows nothing left running, patch and reboot.

Step 5: plan maintenance windows for a multi-tenant cloud

• Size the batch to spare capacity. You can only drain as many hosts at once as your free capacity can absorb. If you keep one host's worth of headroom per cell or cluster, you can drain one host at a time; without it, the first window is shorter than you think.
• Order by exposure. Untrusted tenants and sandboxes first, then CI and build hosts, then internal workloads.
• List guests that will not live migrate before the window. Typical blockers are passthrough devices, pinned VMs and guests whose memory changes faster than the network can copy it.
• Decide on convergence settings in advance. Per the nova docs, live_migration_permit_auto_converge slows the guest's CPU so it can finish, post-copy can reboot the VM if the network drops mid-migration and does not work with VFIO devices including vGPU, and force-complete pauses the instance until memory copy ends.
• Check where guests landed. Nova's default timeout action is abort, which leaves the guest on the old host, so your drain script must check rather than assume.
• Know your interim option and its limits. TuxCare suggests turning off checksum offload on untrusted guests' virtio-net devices for hosts that can be neither patched nor live patched yet. In libvirt XML it looks like this:

<interface type='bridge'>
  <driver>
    <host csum='off'/>
    <guest csum='off'/>
  </driver>
</interface>

TuxCare says it has not tested this, it costs throughput and it needs a full guest restart. On OpenStack, nova generates guest XML itself, so a hand edit with virsh edit is likely to be replaced on hard reboot or migration. It is a stopgap for a few hosts, not a fleet plan.

Step 6: verify every host

Patched means running a fixed kernel or carrying a live patch for this CVE. A package on disk is not enough.

# Running kernel versus installed packages, every host
ansible kvm -m command -a 'uname -r'

# Reboot still pending?
ansible kvm_rhel -m command -a 'needs-restarting -r'
ansible kvm_debian -m shell -a 'test -f /var/run/reboot-required && echo REBOOT-PENDING || echo ok'

# Live patch coverage, where used
kcarectl --patch-info | grep 'CVE-2026-99999'
kpatch list
canonical-livepatch status --verbose

Then close the loop:

1. Diff today's kernel list against your Step 1 snapshot. Every host should have changed or carry a live patch.
2. Compare each running kernel with the vendor's fixed package from Step 2, not with an upstream number.
3. On live patched hosts, uname -r still shows the old kernel. Record the live patch evidence instead.
4. On OpenStack, confirm every nova-compute service is enabled again. A host left disabled is a silent capacity loss.
5. If you pulled AlmaLinux kernels from testing, AlmaLinux says to disable the testing repo again after rebooting.
6. Open a ticket for the expected follow-up fix now, with this host list attached.

What to tell tenants

Tenants cannot patch your hosts or see whether you have, so a short, specific notice saves tickets. Reporting on Netcup's host reboots, heise says customers need take no action but should check that their servers restart automatically after a host reboot. Build on that:

• What and when: the CVE, that you are applying vendor fixes, and the window per region or zone.
• What they will notice: most guests live migrate with a brief pause; name the categories that will be stopped and started instead.
• What they should check: that their services start on boot and their guests are set to restart automatically, in case a cold restart is needed.
• What does not help: patching their own guest kernels does not change exposure to this host flaw.
• Nested virtualisation: if they run their own KVM guests inside your VMs, they are the host for those guests and must patch that kernel themselves.
• Status: where to see progress, and that a second upstream fix is expected.

Subject: Host kernel maintenance for CVE-2026-99999 (PwnEscape), REGION, DATE

We are applying vendor kernel fixes to our virtualisation hosts in REGION
between START and END (UTC). Most instances will be live migrated with a
pause of a few seconds or less. Instances with passthrough devices will be
stopped and started; their owners will receive a separate notice.
No action is required. Please confirm your services start automatically
after a reboot. If you run nested virtual machines, patch that VM's kernel.
Status updates: STATUS_URL

Do not promise a pause length you have not measured. Our post on the IDCF Cloud ransomware incident shows from the tenant side how much clear notices matter.

What would have helped

Practices any team can use

• A host inventory with running and installed kernels, sourced from the control plane. The drain and verify steps become queries.
• Rolling host reboots as routine. Fleets that cycle hosts monthly already have tested drain scripts and known non-migratable guests.
• Pre-agreed tenant maintenance terms, so one email does the job.
• Live patch coverage confirmed in advance for the kernels you actually run.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes, an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is the paid side: hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3+, Sigstore-signed, with evidence pages, and an artifact loses its badge on regression.

For a cloud operator, the habit that transfers is pulling patched, signed components from a curated source and rebuilding fast. That applies to the images and packages in your control plane and tooling, not to your distribution's kernel.

Where Safeguard fits

Plainly: Safeguard does not inventory hypervisor kernels, tell you which hosts need a reboot, or patch host kernels. Images do not include the kernel they run on, so image scanning will not flag PwnEscape. Your configuration management, distribution trackers and live patch provider are the tools here.

Where it can save time this week:

• Drafting and running the rollout with approval. The Safeguard CLI's assistant can edit code and run commands with your approval. On a jump host, ask it to turn this post's drain, verify and re-enable steps into a script for your inventory, and review each command before it runs. /permissions offers Ask, Accept edits, Plan, Auto (the default) and Strict; use Ask or Strict near production. safeguard exec covers CI.
• Approving off-hours windows. The desktop and phone apps can send work to a computer running the CLI and approve each command.
• The rest of the queue. safeguard scan --image NAME and safeguard scan --dir . match your control plane images and repos against vulnerability databases (JSON under ./output). The platform shows which projects contain a given component and version, reachability helps order the work, and gates stop known vulnerable components moving forward. PHP2Shell, from the same week, lives in images like these wherever PHP runs.

None of this would have prevented PwnEscape; the fix is a host kernel update applied by whoever runs the host. For how AI-assisted research surfaced this bug, see how AI found PHP2Shell and PwnEscape, and for the whole month, October 2026 security incidents and what would have helped. To try the CLI for the parts it covers, download it from safeguard.sh/download and read the CLI documentation.

Common mistakes

• Using evacuate for maintenance. Nova's evacuate rebuilds instances and is meant for failed hosts. Use live migration.
• Forgetting to re-enable nova-compute. The host is patched, but the scheduler never sends it work again.
• Trusting the package manager instead of uname -r. Installing a kernel changes nothing until the host boots into it.
• Reading upstream numbers against vendor kernels. AlmaLinux 9's fixed kernel is a 5.14 build.
• Waiting because Ubuntu says Medium. The same page shows CVSS 9.3; exposure depends on whether your guests are trusted.
• Missing hosts outside the control plane. CI runners with /dev/kvm, build hosts and lab hypervisors do not show up in nova or oVirt.
• Closing the ticket after the first patch. The commit and TuxCare both point to a follow-up fix.

FAQ

Do OpenStack compute nodes need a reboot for PwnEscape?

Yes, unless a live patch covering CVE-2026-99999 is applied to the running kernel. Install the vendor's fixed kernel, live migrate guests off, reboot, then confirm the running kernel with uname -r before re-enabling the nova-compute service.

Can I use nova evacuate to empty a compute host for patching?

No. The nova documentation describes evacuate as recovery from a failed host and says not to use it while instances are running. Use openstack server migrate --live-migration per server, or nova host-evacuate-live to drain a host.

What happens to pinned VMs when an oVirt host goes into maintenance?

Per the oVirt Administration Guide, running VMs migrate to other hosts, and VMs pinned to the host that cannot migrate are shut down. Check the Pinned to Host filter first and schedule those with their owners.

Is there a fixed kernel for Ubuntu or RHEL compute hosts yet?

Not as of 21 October 2026. Ubuntu's tracker lists every kernel flavour as Vulnerable with no USN, and Red Hat lists all streams as affected with no erratum. Debian, Oracle Linux UEK, Amazon Linux and Proxmox's 7.0 series have fixes.

Does disabling checksum offload protect my hosts?

It may close the guest path, but TuxCare says it has not tested it, it costs throughput and it needs a full guest restart. On OpenStack, nova may overwrite hand edits to guest XML. Treat it as a stopgap only.

Do tenants need to do anything?

Usually not. They should confirm their services start automatically after a reboot. Tenants running nested KVM guests inside their VMs must patch that VM's kernel, because it acts as the host for those guests.

See how Safeguard would have helped

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. It is a code upgrade, not PwnEscape. Here you would pick the folder holding your Ansible or OpenStack scripts, ask for a drain and verify script for one host, and approve each openstack or ansible command before it runs.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the CLI and approves a command with Allow once, Allow for turn or Deny. For a night window, the on-call engineer could approve each migration or reboot command from a phone and deny anything unexpected.

Click through it at your own pace, or open it full screen.

This real CLI session fixes a lodash CVE, asking before each command and pushing nothing. It cannot patch a host kernel; it shows how you would clear the rest of this week's queue, such as PHP2Shell in any PHP images you run, while kernel work runs through your own tools.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• pwn.ai: PwnEscape, guest-to-host KVM escape (CVE-2026-99999)
• kernel.org: current stable and longterm releases
• Ubuntu security: CVE-2026-99999
• Red Hat: CVE-2026-99999
• Debian security tracker: CVE-2026-99999
• SUSE: CVE-2026-99999
• Oracle Linux: CVE-2026-99999
• AlmaLinux: PwnEscape (CVE-2026-99999) patched kernels
• AWS security bulletin 2026-137-AWS
• Proxmox VE security advisories, including PSA-2026-00068-1
• OpenStack nova: live migrate instances
• OpenStack nova: evacuate instances
• OpenStack nova: manage compute services
• OpenStackClient: server commands
• python-novaclient: nova CLI reference
• oVirt Administration Guide
• libvirt: virsh manual page
• Canonical: Ubuntu Livepatch
• Red Hat: Is live kernel patch (kpatch) supported in RHEL?
• TuxCare: PwnEscape KVM guest escape
• heise online: PwnEscape, critical Linux kernel flaw allows VM escape
• VirtFusion: PwnEscape (CVE-2026-99999)
• Warp2Search: four stable Linux kernels with the PwnEscape fix

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.