Two flaws, two owners
PwnEscape is tracked as CVE-2026-99999. The defect sits in the kernel's IPv4 network stack, in the skb_checksum_help function, and is reached by the traffic a virtual machine sends through virtio-net. The CVSS 3.1 score is 9.3, with a local vector (AV:L). Paulos Yibelo (Pwn.ai) found it during the Vercel Sandbox challenge and demonstrated an escape in the lab on KVM and Firecracker. The exposed kernel is the virtualization host's, not your VPS's.
Vghost is tracked as CVE-2026-74580. It affects the vhost subsystem: a metadata cache for the virtio queues (the vrings) is not cleared when their configuration changes, which bypasses a range validation. A local user who can open /dev/vhost-net or /dev/vhost-vsock can gain root. A proof of concept is public. For both flaws, no in-the-wild exploitation was reported when this guide was written.
Who fixes what
Scroll the table
| Scenario | Where the defect is | Who acts |
|---|---|---|
| PwnEscape (CVE-2026-99999) | Virtualization host kernel, IPv4 network stack | The provider, on its hosts. Nothing can be fixed from your VPS |
| Vghost (CVE-2026-74580), VPS side | Your VPS kernel, if the `/dev/vhost-*` nodes are reachable | You: fixed kernel, then reboot |
| Vghost, path triggered from a guest | Host kernel and QEMU, under specific conditions | The provider |
| Updating the guest kernel against PwnEscape | The defect is on the host | No protection on this side; it remains useful for Vghost and other fixes |
| Dedicated server or VPS where you are the hypervisor (KVM, Proxmox) | You are the host | You: both flaws concern you |
| Docker containers on the VPS | They share the VPS kernel | Fix the VPS kernel; rebuilding an image changes nothing |
| cPanel shared hosting | Kernel managed by the provider | The provider |
PwnEscape: the provider's job
For an escape, the kernel that receives the virtual machine's traffic must be fixed, which means the host's. The fixed stable branches are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 and 7.2.11; distribution kernels often backport a fix without changing the base number, so read the distribution's bulletin rather than comparing numbers. The CVE record also shows version bounds that do not add up: rely on the distribution trackers.
On a VPS you cannot apply this fix, and updating your guest kernel does not protect you from it. Ask your provider, whoever it is, whether its hosts are fixed, on what date, and whether a host reboot is planned. We do not claim here that a specific offer is or is not vulnerable: only the operator's confirmation counts. In his article, the researcher predicts public exploits for the weakest configurations within weeks: that is his forecast, not an observation, and CISA's assessment reports no exploitation so far.
Vghost: your job
Vghost is a local escalation: the attacker must already run code on the machine, for example through a compromised client site running under an unprivileged account. The mainline fix is commit de845981da67. The first fixed stable releases are 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 and 7.2. Again, a distribution kernel may carry the fix under another number: compare with the distribution's bulletin, not the upstream number.
Everything depends on the permissions of the vhost nodes. According to the oss-security announcement, in its author's tests, Ubuntu limited /dev/vhost-vsock to the kvm group, while RHEL, Amazon Linux, Azure Linux and Oracle Linux opened it to any user. On a VPS that hosts no virtual machine, these nodes are normally absent; check, do not assume. The fix only takes effect after rebooting into the new kernel.
Check the kernel and the exposure in ten minutes
Read the running kernel
uname -r
This prints the kernel loaded in memory, not the one installed on disk. This is the number that matters for Vghost, and it only changes after a reboot.List installed kernels
dpkg -l 'linux-image*' | grep '^ii'rpm -q kernel
The first command is for Debian and Ubuntu, the second for AlmaLinux, Rocky and RHEL. If the newest kernel in the list differs from the one inuname -r, a fix may be installed without being active.Know whether a reboot is pending
cat /var/run/reboot-requiredsudo needrestart -ksudo dnf needs-restarting -r
The first two apply to Debian and Ubuntu, the third to AlmaLinux and Rocky (dnf-utilspackage if the command is missing). They compare the running kernel with the installed one.Look for vhost nodes and their permissions
ls -l /dev/vhost-net /dev/vhost-vsocklsmod | grep '^vhost'getent group kvm
With no node and no module loaded, the path described for Vghost is not open right now, but software or an administrator can load the module later. If a node exists, read its mode:0666means any local account can open it,0660means membership of the owning group is required. If you run virtual machines yourself, addls -l /dev/kvm.Look for the identifier in the package changelog
apt changelog linux-image-$(uname -r) | grep CVE-2026-74580rpm -q --changelog kernel | grep CVE-2026-74580
The first line is for Debian and Ubuntu, the second for the RHEL family. Finding the identifier is a good sign; not finding it proves nothing, since the changelog may cite the fix differently. The distribution tracker settles it.Handle containers and device access
docker exec <container> uname -rdocker ps -q | xargs -r docker inspect | grep -E 'Privileged|vhost'
The first command prints the VPS kernel, proof that the container has none of its own. The second spots containers started in privileged mode or with a vhost device mounted: they see the host's nodes.
Where the distributions stand
The state of fixes changes from one day to the next and differs between distribution releases, some being fixed before others. Reread your distribution's tracker for both identifiers, CVE-2026-74580 and CVE-2026-99999, before concluding: the links are at the end of the article. For AlmaLinux and Rocky, follow the errata each project publishes after RHEL's. As long as your release shows no published fix, apply a temporary mitigation and check back.
Update according to your environment
Debian and Ubuntu
sudo apt updatesudo apt full-upgradeapt list --installed 'linux-image*'
Usefull-upgrade: a new kernel arrives under a new package name, andapt upgradeoften leaves it aside ("kept back"). If the tracker says the fix is not yet published for your release, updating brings nothing on this point: apply a temporary mitigation and check back regularly.AlmaLinux, Rocky and RHEL
sudo dnf upgrade --refresh kernelsudo grubby --default-kernelsudo dnf needs-restarting -r
The second command confirms the installed kernel is the one that will boot by default. The third says whether the system is waiting for a reboot.Docker and containers
There is nothing to rebuild: containers use the VPS kernel. Update the machine's kernel as above, then reboot it. After the reboot, check that every container came back:
docker psanddocker ps -a --filter status=exited. Arestart: unless-stoppedpolicy in your Compose files saves restarting by hand.Home-run hypervisor (KVM, Proxmox)
You are the host, so both flaws concern you. Apply the same updates on the host, then reboot it after migrating or cleanly stopping the virtual machines. Keep the host up to date before the guests, not after.
An installed kernel is not a running kernel
A successful apt full-upgrade fixes nothing until the machine reboots: the vulnerable kernel stays loaded in memory. The only valid check is uname -r after the reboot, compared with the number expected in your distribution's bulletin. Write it in your register, with the date, for each server.
Rebooting without cutting client sites
Plan rather than endure. Pick a quiet window, warn clients, check that your backups are recent, then schedule the reboot: sudo shutdown -r 03:30 "Kernel reboot". Before, note the service state with systemctl --failed and the container list with docker ps; after, replay the same commands and compare. Handle the fleet in batches of a few machines.
Livepatch can avoid a reboot, but its availability depends on the distribution and the subscription: Canonical Livepatch on Ubuntu with Ubuntu Pro, kpatch on the RHEL family, KernelCare from a third-party vendor. Do not assume a live fix exists for these two flaws: read the vendor's bulletin and, on Ubuntu, canonical-livepatch status --verbose. The Vghost advisory asks for a reboot into the fixed kernel; without a confirmed livepatch, it is the only way.
Temporary mitigations and their limits
If your distribution's fix is not published yet, two moves reduce the Vghost surface without closing it. The first removes general access to the nodes, for example sudo chmod 0660 /dev/vhost-net /dev/vhost-vsock, then keeps untrusted containers away from these devices. It does not revoke descriptors that are already open. The second, which the Red Hat page for Vghost lists as a mitigation, prevents the modules from loading: printf 'install vhost_net /bin/false\ninstall vhost_vsock /bin/false\n' | sudo tee /etc/modprobe.d/vhost-off.conf, then sudo modprobe -r vhost_net vhost_vsock. Red Hat warns that turning off vhost can degrade virtual machine I/O performance, and that unloading fails if the driver is in use.
These measures do nothing against PwnEscape, whose defect is on the host, and none replaces the fixed kernel. Restore the original configuration once the fix is applied.
Checking the traces afterwards
To our knowledge no indicator of compromise specific to these flaws has been published, which makes the check imperfect. Still, go through what can betray a recent privilege escalation: sudo journalctl -k --since "30 days ago" | grep -i -E 'vhost|oops|general protection' for kernel anomalies, last -x | head -30 for logins and reboots, sudo awk -F: '$3==0' /etc/passwd for root-level accounts, then the keys in /root/.ssh/authorized_keys and root's crontab -l tasks. Also look for recent setuid binaries with sudo find / -xdev -perm -4000 -mtime -30.
An attacker who became root can erase their tracks: a clean check is not proof of health. If in doubt about a server that has run untrusted code, rebuild it from a clean image and restore the data instead of cleaning it.
For an agency: one shared window, not one server at a time
With dozens of VPS at different clients, the update command takes a minute; the time goes into knowing which server runs which kernel, who approves the reboot and when. Keep a living register fed by uname -r and by the presence of /var/run/reboot-required, then set a shared window announced in advance instead of discovering the flaw server by server. Sort first the machines where untrusted client code runs, then those where /dev/vhost-* exists.
The ServOrbit agency area centralizes services and due dates, so you do not follow them account by account. For those who would rather not manage the kernel themselves, ServOrbit offers the VPS administration option; this guide, for its part, is provided without support.
The official documentation
Vghost disclosure on oss-security: https://openwall.com/lists/oss-security/2026/10/14/2
Vghost technical analysis: https://matrix.tencent.com/en/2026/10/12/vghost-cve-2026-74580
PwnEscape CVE record: https://cveawg.mitre.org/api/cve/CVE-2026-99999
PwnEscape discoverer's article: https://pwn.ai/blog/pwnescape
Debian tracker for Vghost: https://security-tracker.debian.org/tracker/CVE-2026-74580
Debian tracker for PwnEscape: https://security-tracker.debian.org/tracker/CVE-2026-99999
Ubuntu tracker for Vghost: https://ubuntu.com/security/CVE-2026-74580
Ubuntu tracker for PwnEscape: https://ubuntu.com/security/CVE-2026-99999
Red Hat page for Vghost: https://access.redhat.com/security/cve/CVE-2026-74580
AlmaLinux errata: https://errata.almalinux.org/
Canonical Livepatch: https://ubuntu.com/security/livepatch
needrestart tool: https://github.com/liske/needrestart
