[{"data":1,"prerenderedAt":193},["ShallowReactive",2],{"seo-verification":3,"blog-pwnescape-vghost-linux-kernel-vps-update-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-pwnescape-vghost-linux-kernel-vps-update-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":139,"ctaBody":140,"ctaButton":141,"ctaUrl":142,"relatedPosts":143},517,"pwnescape-vghost-linux-kernel-vps-update",{"fr":12,"en":10,"ar":13,"es":14},"pwnescape-vghost-noyau-linux-vps-mettre-a-jour","ثغرتا-pwnescape-و-vghost-تحديث-نواة-لينكس-على-vps","pwnescape-vghost-kernel-linux-vps-actualizar","PwnEscape and Vghost: update the Linux kernel on your VPS","Two Linux kernel flaws from October 2026: PwnEscape is fixed by your host, Vghost on your VPS. Check the kernel, update it and schedule the reboot.",11,0,false,"2026-10-28T00:00:00+00:00","2026-10-29T03:10:22+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fpwnescape-vghost-noyau-linux-vps-mettre-a-jour-poster.svg","In mid-October 2026, two Linux kernel flaws went public: PwnEscape, which lets a virtual machine escape to its host, and Vghost, a local privilege escalation to root with a public proof of concept. On a VPS the question is not whether to update, but who updates what. The virtualization host is your provider's job; the kernel of your VPS is yours, and it only gets fixed at reboot. This guide gives the commands per distribution, the exposure check and a reboot plan that spares client sites.",[35,39,74,77,80,102,105,120,124,127,130,133,136],{"type":36,"title":37,"body":38},"h2","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.\n\nVghost 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 `\u002Fdev\u002Fvhost-net` or `\u002Fdev\u002Fvhost-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.",{"type":40,"title":41,"headers":42,"rows":46},"comparison","Who fixes what",[43,44,45],"Scenario","Where the defect is","Who acts",[47,51,55,59,63,67,71],[48,49,50],"PwnEscape (CVE-2026-99999)","Virtualization host kernel, IPv4 network stack","The provider, on its hosts. Nothing can be fixed from your VPS",[52,53,54],"Vghost (CVE-2026-74580), VPS side","Your VPS kernel, if the `\u002Fdev\u002Fvhost-*` nodes are reachable","You: fixed kernel, then reboot",[56,57,58],"Vghost, path triggered from a guest","Host kernel and QEMU, under specific conditions","The provider",[60,61,62],"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",[64,65,66],"Dedicated server or VPS where you are the hypervisor (KVM, Proxmox)","You are the host","You: both flaws concern you",[68,69,70],"Docker containers on the VPS","They share the VPS kernel","Fix the VPS kernel; rebuilding an image changes nothing",[72,73,58],"cPanel shared hosting","Kernel managed by the provider",{"type":36,"title":75,"body":76},"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.\n\nOn 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.",{"type":36,"title":78,"body":79},"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.\n\nEverything depends on the permissions of the vhost nodes. According to the oss-security announcement, in its author's tests, Ubuntu limited `\u002Fdev\u002Fvhost-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.",{"type":81,"title":82,"steps":83},"steps","Check the kernel and the exposure in ten minutes",[84,87,90,93,96,99],{"title":85,"body":86},"Read the running kernel","`uname -r`\nThis 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.",{"title":88,"body":89},"List installed kernels","`dpkg -l 'linux-image*' | grep '^ii'`\n`rpm -q kernel`\nThe 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 in `uname -r`, a fix may be installed without being active.",{"title":91,"body":92},"Know whether a reboot is pending","`cat \u002Fvar\u002Frun\u002Freboot-required`\n`sudo needrestart -k`\n`sudo dnf needs-restarting -r`\nThe first two apply to Debian and Ubuntu, the third to AlmaLinux and Rocky (`dnf-utils` package if the command is missing). They compare the running kernel with the installed one.",{"title":94,"body":95},"Look for vhost nodes and their permissions","`ls -l \u002Fdev\u002Fvhost-net \u002Fdev\u002Fvhost-vsock`\n`lsmod | grep '^vhost'`\n`getent group kvm`\nWith 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: `0666` means any local account can open it, `0660` means membership of the owning group is required. If you run virtual machines yourself, add `ls -l \u002Fdev\u002Fkvm`.",{"title":97,"body":98},"Look for the identifier in the package changelog","`apt changelog linux-image-$(uname -r) | grep CVE-2026-74580`\n`rpm -q --changelog kernel | grep CVE-2026-74580`\nThe 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.",{"title":100,"body":101},"Handle containers and device access","`docker exec \u003Ccontainer> uname -r`\n`docker ps -q | xargs -r docker inspect | grep -E 'Privileged|vhost'`\nThe 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.",{"type":36,"title":103,"body":104},"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.",{"type":81,"title":106,"steps":107},"Update according to your environment",[108,111,114,117],{"title":109,"body":110},"Debian and Ubuntu","`sudo apt update`\n`sudo apt full-upgrade`\n`apt list --installed 'linux-image*'`\nUse `full-upgrade`: a new kernel arrives under a new package name, and `apt upgrade` often 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.",{"title":112,"body":113},"AlmaLinux, Rocky and RHEL","`sudo dnf upgrade --refresh kernel`\n`sudo grubby --default-kernel`\n`sudo dnf needs-restarting -r`\nThe 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.",{"title":115,"body":116},"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 ps` and `docker ps -a --filter status=exited`. A `restart: unless-stopped` policy in your Compose files saves restarting by hand.",{"title":118,"body":119},"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.",{"type":121,"title":122,"body":123},"tip","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.",{"type":36,"title":125,"body":126},"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.\n\nLivepatch 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.",{"type":36,"title":128,"body":129},"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 \u002Fdev\u002Fvhost-net \u002Fdev\u002Fvhost-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 \u002Fbin\u002Ffalse\\ninstall vhost_vsock \u002Fbin\u002Ffalse\\n' | sudo tee \u002Fetc\u002Fmodprobe.d\u002Fvhost-off.conf`, then `sudo modprobe -r vhost_net vhost_vsock`. Red Hat warns that turning off vhost can degrade virtual machine I\u002FO performance, and that unloading fails if the driver is in use.\n\nThese 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.",{"type":36,"title":131,"body":132},"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' \u002Fetc\u002Fpasswd` for root-level accounts, then the keys in `\u002Froot\u002F.ssh\u002Fauthorized_keys` and root's `crontab -l` tasks. Also look for recent setuid binaries with `sudo find \u002F -xdev -perm -4000 -mtime -30`.\n\nAn 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.",{"type":36,"title":134,"body":135},"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 `\u002Fvar\u002Frun\u002Freboot-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 `\u002Fdev\u002Fvhost-*` exists.\n\nThe 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.",{"type":36,"title":137,"body":138},"The official documentation","Vghost disclosure on oss-security: https:\u002F\u002Fopenwall.com\u002Flists\u002Foss-security\u002F2026\u002F10\u002F14\u002F2\n\nVghost technical analysis: https:\u002F\u002Fmatrix.tencent.com\u002Fen\u002F2026\u002F10\u002F12\u002Fvghost-cve-2026-74580\n\nPwnEscape CVE record: https:\u002F\u002Fcveawg.mitre.org\u002Fapi\u002Fcve\u002FCVE-2026-99999\n\nPwnEscape discoverer's article: https:\u002F\u002Fpwn.ai\u002Fblog\u002Fpwnescape\n\nDebian tracker for Vghost: https:\u002F\u002Fsecurity-tracker.debian.org\u002Ftracker\u002FCVE-2026-74580\n\nDebian tracker for PwnEscape: https:\u002F\u002Fsecurity-tracker.debian.org\u002Ftracker\u002FCVE-2026-99999\n\nUbuntu tracker for Vghost: https:\u002F\u002Fubuntu.com\u002Fsecurity\u002FCVE-2026-74580\n\nUbuntu tracker for PwnEscape: https:\u002F\u002Fubuntu.com\u002Fsecurity\u002FCVE-2026-99999\n\nRed Hat page for Vghost: https:\u002F\u002Faccess.redhat.com\u002Fsecurity\u002Fcve\u002FCVE-2026-74580\n\nAlmaLinux errata: https:\u002F\u002Ferrata.almalinux.org\u002F\n\nCanonical Livepatch: https:\u002F\u002Fubuntu.com\u002Fsecurity\u002Flivepatch\n\nneedrestart tool: https:\u002F\u002Fgithub.com\u002Fliske\u002Fneedrestart","A fleet of VPS, one reboot window","A fleet of client servers is easier to run from one place. In the ServOrbit.com agency area, you centralize services and due dates; the VPS administration option exists for those who would rather not manage the kernel themselves.","Discover the agency offer","\u002Fsolutions\u002Fagences",[144,160,177],{"id":145,"slug":146,"slugs":147,"title":151,"excerpt":152,"readTime":17,"views":153,"isPinned":19,"publishedAt":154,"updatedAt":155,"category":156,"categories":157,"featuredImage":30,"bgImage":31,"posterImage":159,"relatedSolution":30},317,"linux-vps-hardening-checklist-for-agencies",{"fr":148,"en":146,"ar":149,"es":150},"linux-hardening-vps-checklist","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Linux VPS Hardening Checklist for Agencies","Reproducible Linux hardening checklist for agencies: auditd, sudo user, SSH key auth, UFW, fail2ban and root lockout — with per-client traceability.",1,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[158],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",{"id":161,"slug":162,"slugs":163,"title":167,"excerpt":168,"readTime":169,"views":170,"isPinned":19,"publishedAt":171,"updatedAt":172,"category":173,"categories":174,"featuredImage":30,"bgImage":31,"posterImage":176,"relatedSolution":30},382,"vps-automatic-security-updates-debian-ubuntu",{"fr":164,"en":162,"ar":165,"es":166},"securite-vps-mises-a-jour-automatiques-debian-ubuntu","تحديثات-أمان-تلقائية-vps-debian-ubuntu","actualizaciones-seguridad-vps-debian-ubuntu","Automatic Security Updates on Debian\u002FUbuntu VPS","Configure unattended-upgrades on your Debian\u002FUbuntu VPS to automate security patches and reduce attack surface across your client fleet.",10,2,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[175],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg",{"id":178,"slug":179,"slugs":180,"title":184,"excerpt":185,"readTime":186,"views":153,"isPinned":19,"publishedAt":187,"updatedAt":188,"category":189,"categories":190,"featuredImage":30,"bgImage":31,"posterImage":192,"relatedSolution":30},494,"openssh-10-6-security-update-sshd",{"fr":181,"en":179,"ar":182,"es":183},"openssh-10-6-mise-a-jour-securite-sshd","تحديث-openssh-10-6-أمان-sshd","openssh-10-6-actualizacion-seguridad-sshd","OpenSSH 10.6: update sshd without losing access","OpenSSH 10.6 security update: check the version actually running, what may break (ProxyCommand, Compression) and reload sshd safely.",12,"2026-10-22T00:00:00+00:00","2026-10-23T13:27:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[191],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fopenssh-10-6-mise-a-jour-securite-sshd-poster.svg",1793251371791]