PwnEscape for VM tenants: what providers said and what to ask yours

If you rent virtual machines, PwnEscape (CVE-2026-99999) is a flaw in your provider's host kernel, not in your VM. You cannot patch it yourself. Your job is to find out whether your provider's hosts are fixed, prepare your VMs for surprise host reboots, and keep a written record of what the provider told you and when.

Our PwnEscape explainer covers the bug, the fix commit and the distro status. This post is for the other side of the hypervisor: teams that run workloads on someone else's KVM hosts, from a single VPS to a fleet of cloud instances.

Why this one lands on tenants

Most kernel bugs you fix inside your own server. Here the flawed code runs in the host's IPv4 networking path, and the dangerous input comes from a guest VM. The CVE record, published by the Linux kernel CNA on 15 October, describes packets with bad checksum metadata that can make the host corrupt a network header it has already checked. pwn.ai, the research team that found it, showed host memory disclosure and a bounded host root chain on its own lab machines, and says it makes no claim about any vendor's production systems.

For a tenant, three things follow:

1. The attacker is a neighbour, not you. The risky guest is any other VM on the same physical host. That guest controls its own network settings, so nothing you configure in your own VM changes what a hostile neighbour can send to the host.
2. Your guest kernel update does not help with the neighbour. Patching the kernel inside your VM is still good hygiene, but the host kernel is the one that needs the fix.
3. The fix usually means a host reboot. Unless your provider live patches or live migrates you, the VM you rent will stop and start again at a time you did not choose.

heise reports the researchers "expect working exploits to circulate underground within a few weeks". We found no confirmed in-the-wild exploitation as of 21 October. That gap is your window to get answers.

What providers have published so far

We checked each provider's own pages on 21 October 2026 where we could reach them. This table records what each one said publicly. It is not a ranking. Providers run different architectures, and silence on a public page does not tell you the state of their hosts.

A few notes on the table:

• AWS's version range differs from the CVE record. The bulletin describes affected hosts as running kernels 4.4 through 6.18. The CVE record lists the bug as present from Linux 2.6.27 and lists fixes up to the 7.2 series. If you run your own hypervisor, check against your distribution's tracker rather than either range alone.
• UpCloud. We could not load UpCloud's own post. A summary on vpsranking.com reports that UpCloud named Cloud Server, Private Cloud and GPU Server as in scope, said GPU servers cannot be live migrated and expected 30 to 60 minutes of downtime for them, and said no customer action was needed at that stage. Check UpCloud's page before relying on this.
• No statement found. We did not find a public statement on CVE-2026-99999 from Microsoft Azure, OVHcloud or DigitalOcean as of 21 October. That is not evidence either way. Ask them.

Timeline for tenants

The questions to send your provider

A short, specific ticket gets a better answer than "are we safe?". These are the questions we would send, and why each matters.

1. Are the hypervisor hosts that run our instances affected by CVE-2026-99999? Some managed platforms say they are not affected. You want that in writing for your account and region.
2. If affected, what is the fix status today: patched, live patched, mitigated, or pending? Hetzner describes a temporary mitigation, RackNerd describes live patching, Contabo describes reboots. These are different states with different residual risk.
3. If you are using a mitigation, is it a full fix? A mitigation that detects the attack vector is not the same as a fixed kernel. Ask when the fixed kernel will be in place.
4. Will our instances be rebooted, live migrated, or neither? This decides whether you need a maintenance window.
5. How much notice will we get, and through which channel? Email, status page, API event, or none. Contabo said individual customers get no advance notice.
6. Can we choose or move our maintenance window? Some clouds let you reschedule or trigger maintenance early.
7. What happens to instance types that cannot live migrate? GPU, bare metal and some large memory types usually need a stop and start.
8. Do you expect a second patch? The fix commit calls itself defence in depth, and TuxCare expects a second upstream fix. Ask whether another round of reboots is planned.
9. Have you seen any evidence of exploitation on your platform? RackNerd and UpCloud both said publicly they had none. Ask yours.
10. Who should we contact, and where will updates appear? Get a status page URL or ticket reference you can cite later.

A copy ready version:

Subject: CVE-2026-99999 (PwnEscape) host status for account <ACCOUNT_ID>

Hello,

We run workloads on your virtual machines in <REGIONS>. For our records,
please confirm the following about CVE-2026-99999 (PwnEscape):

1. Are the hypervisor hosts running our instances affected?
2. Current status: patched, live patched, mitigated, or pending?
3. If mitigated, when will a fixed kernel be in place?
4. Will our instances be rebooted, live migrated, or neither?
5. How much notice will we receive, and through which channel?
6. Can we choose or reschedule the window?
7. How are GPU, bare metal or other non-migratable types handled?
8. Do you expect a second round of host updates for this CVE?
9. Have you seen any sign of exploitation on your platform?
10. Where will you post updates (status page URL or ticket)?

Thank you.

Send it per provider and per account, and save the reply exactly as received.

Reboot notices and auto restart settings

For most tenants, the visible effect of PwnEscape will be a restarted VM. The big clouds expose maintenance events you can read; smaller hosts often do not.

AWS

AWS can schedule instance events such as instance-reboot (the host gets maintenance while you stay on it) and system-reboot (you are moved to a new host). AWS emails the account contact address and raises an AWS Health event. You can read pending events from the CLI.

aws ec2 describe-instance-status \
  --instance-ids i-1234567890abcdef0 \
  --query 'InstanceStatuses[].Events'

Some events can be rescheduled, and you can set custom event windows. AWS says EC2 is not affected by PwnEscape, so this is about being ready for whichever event comes next.

Microsoft Azure

Azure's Scheduled Events service runs on the instance metadata endpoint inside each VM. Events include Freeze, Reboot and Redeploy, with a minimum notice of 15 minutes for Freeze and Reboot and 10 minutes for Redeploy. Microsoft recommends polling often.

curl -H Metadata:true \
  "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"

An empty Events array means nothing is scheduled. Once your workload is ready, you can approve an event early with a POST that names its EventId.

Google Cloud

Compute Engine's host maintenance policy decides whether a VM live migrates or stops during host maintenance. By default most VMs live migrate and restart automatically after a host error; Spot and preemptible VMs default to terminate and no restart. GPU, TPU, bare metal and some other types support only terminate. To see whether an instance has upcoming maintenance:

gcloud compute instances describe INSTANCE_NAME \
  --zone=ZONE_NAME \
  --format="yaml(resourceStatus.upcomingMaintenance)"

To make sure a VM comes back after a host error:

gcloud compute instances set-scheduling INSTANCE_NAME \
  --zone=ZONE_NAME --restart-on-failure

VPS hosts

Most VPS hosts announce maintenance by email or on a status page, if at all. For each host you use:

• Subscribe to its status page by email or RSS.
• Make sure the account email reaches a shared, monitored inbox, not one person.
• Check the control panel for a setting that boots the VM after host maintenance. Names vary; some panels call it autostart or boot on host start. If you cannot find one, ask support.

Inside the VM: make a surprise reboot boring

A host reboot is a cold boot for your VM. Anything that does not start on its own stays down until someone notices. Run these checks on each VM.

# When did this VM last boot, and how many boots are on record?
uptime -s
journalctl --list-boots | tail -5

# Which services start on boot? Check the ones you care about.
systemctl is-enabled nginx postgresql docker 2>/dev/null
systemctl --failed

# Docker containers: restart policy per container
docker ps -a --format '{{.Names}}' | while read n; do
  echo "$n: $(docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' "$n")"
done

Fix what you find:

1. Enable each service you need at boot with systemctl enable, then confirm it is listed as enabled.
2. Give long lived containers a restart policy such as unless-stopped, or run them under systemd or your orchestrator.
3. Check mounts. A data volume missing from /etc/fstab, or one that blocks boot when absent, is a common cause of a VM that "came back" without its data.
4. Check tmpfs and in memory state. Queues, caches and session stores held only in memory are lost on a reboot.
5. Test it. Reboot one VM yourself in a quiet hour. If it does not come back cleanly, you found the problem before the host maintenance did.
6. Alert on reboots. Compare uptime -s with the last known value so you know when a host reboot hit you.

What you can do inside your own VMs

Honestly, not much about PwnEscape itself. Here is what is in your control.

• Patch your guest kernel anyway. It does nothing against a neighbour, but the CVE also touches TUN and packet socket code. If your VM runs containers, CI jobs or anything else with untrusted local users, it plays a host role of its own. TuxCare notes that on Enterprise Linux 8 to 10 the default udev rules leave /dev/kvm world writable, which matters if your VM supports nested virtualisation.
• If you run a hypervisor inside your cloud account, you are the host. Firecracker on bare metal instances, nested KVM, or a self-built sandbox platform: AWS's bulletin says self-managed KVM and Firecracker hosts on unpatched kernels are affected. Patch and reboot those yourself. The OpenStack and libvirt guide covers the operator side.
• Do not rely on guest side network tweaks. TuxCare's interim idea of turning off checksum offload is a host side QEMU or libvirt setting applied to untrusted guests. Changing offload inside your own VM does not stop a hostile neighbour, which controls its own settings.
• Keep backups off the host. If a host crashes during patching, or worse, you want a recent copy somewhere else. Contabo's notice asks customers to make sure they have recent backups. Our IDCF Cloud write-up covers why backups should not sit with the same provider.
• Reduce what lives in memory. Host memory disclosure is the demonstrated impact in pwn.ai's lab. You cannot prevent that, but you can avoid long lived plaintext secrets in process memory where a short lived token would do.
• Decide about sensitive workloads. If a workload cannot accept shared host risk until your provider confirms a fix, consider dedicated hosts, single tenant instances, or a temporary move. Record the decision.

What to record for audits

Auditors will not ask whether you patched the provider's kernel. They will ask how you knew your provider handled it. Supplier controls in frameworks like ISO 27001 (Annex A 5.19 to 5.23, supplier relationships and cloud services) and SOC 2 (CC9.2, vendor risk) expect evidence that you monitored a critical supplier during a known event. A short record now saves a long reconstruction later.

Keep it with your vendor register entry for that provider, logged as a supplier security event.

What would have helped

Practices any team can use

• A provider list that maps to workloads. Which services run where, in which region, on which instance types. Without it, the questions above go to the wrong place.
• Reboot readiness as a standard. Every VM should survive an unattended cold boot, tested on a schedule.
• Maintenance events wired into alerts. Provider maintenance feeds only help if something reads them.
• Contract terms on notice. At renewal, ask how much notice you get for emergency host maintenance.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in 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. Host kernels are not one of them, so it is not the tool that would surface a bug like PwnEscape.

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, a free read API, and a GitHub Action for CI gating. Gold Registry at registry.safeguard.sh is a paid source of hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses. Neither ships your provider's host kernel. The habit they support applies to what you control: pull patched, signed components from a curated source and rebuild fast.

Where Safeguard fits

To be direct: Safeguard cannot see or patch your provider's hosts, read provider maintenance feeds, or tell you whether a host is fixed. A container image does not include the host kernel, so scanning images will not flag PwnEscape. Your provider, its status page and your own records are what count here.

Where it does help this week:

• Everything inside your VMs. safeguard scan --dir ., safeguard scan --image NAME and safeguard scan --sbom FILE match what you ship against vulnerability databases, with results as JSON under ./output. The platform shows which projects contain a given component and version, and reachability analysis helps you order the work. That matters now, because PHP2Shell landed the same week and does live inside images.
• Writing the checks. The Safeguard CLI's assistant can edit code and run commands with your approval. Ask it to turn the reboot readiness checks above into a script, or to draft the provider ticket, and review each command before it runs. /permissions sets Ask, Accept edits, Plan, Auto (the default) or Strict.
• Approvals off hours. The desktop and phone apps can send work to a computer running the CLI and approve each command, which helps when a provider reboots you at 3 a.m.

None of this would have prevented PwnEscape. You can download the CLI from safeguard.sh/download and read the CLI documentation.

Common mistakes

• Patching your own guest kernel and calling it done. It is worth doing, but the host is what matters here.
• Reading "no statement" as "not affected". Several providers had published nothing we could find. Ask.
• Treating a mitigation as a fix. A detection based mitigation buys time; a fixed host kernel or live patch closes the bug.
• Assuming your VM will come back. Services that are not enabled at boot, containers without restart policies and missing mounts all fail quietly after a host reboot.
• Sending maintenance email to one person. Notices that land in a former employee's inbox do not count as notice.
• Forgetting the second round. The fix is described as defence in depth with more validation to come. Expect another host update.
• Keeping no record. If the answer lived only in a chat thread, you will not find it when the auditor asks.

FAQ

Do I need to patch anything if I only rent VMs?

Not for PwnEscape itself. The host kernel is your provider's responsibility. Do patch your guest kernel as routine, make sure your VMs survive a reboot, and get your provider's status in writing.

Is my AWS EC2 instance affected by PwnEscape?

AWS says Amazon EC2, AWS Lambda and AWS Fargate are not affected and need no customer action. If you run your own KVM or Firecracker hosts on AWS, such as on bare metal instances, AWS says to install fixed kernels and reboot those hosts.

Has Google Cloud or Azure said anything?

When we checked on 21 October, Google Cloud's security bulletins page had no entry for CVE-2026-99999, and we found no public Azure statement. Open a support case if you need an answer for your account.

Why did my VPS reboot without warning?

If your provider is patching hosts for PwnEscape, that is a likely reason. Contabo said it would not give individual advance notice, and heise reported netcup rebooting hosts over a weekend. Check your provider's status page and record the time with journalctl --list-boots.

Can I protect my VM from a malicious neighbour myself?

Not against this bug. The attacking guest controls its own network metadata, and the flaw is in the host. Your options are to wait for your provider's fix, move sensitive workloads to dedicated or single tenant hosts, or reduce what a host memory leak could expose.

What should we keep for our auditor?

The provider's statement with the date you saved it, your question and their reply, the list of affected VMs, reboot timestamps, your guest kernel versions, and a dated risk decision with an owner.

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. For a tenant, you would pick the folder with your server configs, ask for a script that checks boot enabled services, container restart policies and fstab on each VM, and approve each command it wants to run.

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. If a provider reboots your hosts overnight, whoever is on call could ask for the post reboot checks from a phone and approve each systemctl or docker command as it comes up.

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

This session sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. It does not touch host kernels. With PwnEscape in your provider's hands, you would use the same flow to scan the images and repos you deploy to those VMs, so this week's PHP2Shell and library fixes keep moving.

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

Quick check

Sources

• CVE record: CVE-2026-99999
• pwn.ai: PwnEscape, guest-to-host KVM escape (CVE-2026-99999)
• AWS security bulletin 2026-137-AWS
• Google Cloud security bulletins
• Hetzner status: CVE-2026-99999 (PwnEscape)
• Contabo: urgent patching of all VPS/VDS hosts (CVE-2026-99999)
• Sakura Internet: impact of CVE-2026-99999 on its services (Japanese)
• Sakura VPS: response status for CVE-2026-99999 (Japanese)
• Sakura Cloud: response status for CVE-2026-99999 (Japanese)
• RackNerd status: proactive KVM VPS security maintenance (CVE-2026-99999)
• heise online: PwnEscape, critical Linux kernel flaw allows VM escape
• TuxCare: PwnEscape KVM guest escape
• vpsranking.com: UpCloud kernel mitigation summary
• AWS: scheduled events for Amazon EC2 instances
• Microsoft Learn: Scheduled Events for Linux VMs in Azure
• Google Cloud: host maintenance overview
• Google Cloud: set the host maintenance policy
• Google Cloud: monitor and plan for host maintenance events

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