There is a report of a guest-to-host escape in KVM that cannot be patched, because neither the patch nor the number identifying it exists yet. What can be measured today is how far such an escape would reach inside a Proxmox cluster. It is fewer steps than people count.
On Tuesday 6 October 2026, The Register reported that researcher Paulos Yibelo posted on X "a screenshot of a bug bounty award he won for discovering what he described as 'Full VM escape zeroday (guest>host root in industry standard hypervisors)!'", and that Vercel's CEO, Guillermo Rauch, wrote: "We've confirmed a KVM 0day through our Vercel Sandbox bounty program". The same article spells out why this lands on those of us who make a living from virtualization, and names the house: "Enterprise virtualization players Nutanix, HPE, and Proxmox also rely on KVM".
What is known and what is not
- As of today there is no assigned CVE, no NVD entry, no vendor advisory, no patch and no release notes mentioning it. There is no public technical detail either. The Register puts it in writing: "The Register can find no chat on relevant mailing lists. We have asked Rauch and Yibelo for additional details."
- Nobody has said where the bug is. "KVM" in a short sentence can be the kernel module or the userspace program that drives it, and for your maintenance calendar those are not the same. There are no versions either.
- The figure going around is worth reading slowly, because the source says something else: The Register writes that "observers have suggested the potential seriousness of the flaw means Yibelo's reward should exceed the $50,000 available under Vercel's bug bounty program". That is, 50,000 dollars is the programme's ceiling, and what that article records is the view that more should have been paid. It is not, there, the confirmed amount.
- And the context it appeared in: Vercel Sandbox's documentation describes the service as "run untrusted or agent-generated code in isolated Linux microVMs", with "full root access" inside each box and each box in "a secure Firecracker microVM". In that programme, root in the guest is the starting point they hand you. In your data centre it has to be earned first, unless the VM is an exposed web server, a shared development environment or something running whatever an agent hands it.
On Proxmox, it is one hop
When people read "guest>host root", the mental count is usually two steps: first you break out of the guest into the hypervisor process, then you escalate to root on the machine. On Proxmox VE that second step does not exist, and its own QEMU/KVM documentation says so:
QEMU inside Proxmox VE runs as a root process, since this
is required to access block and PCI devices.The same page explains why: "From the perspective of the host system where QEMU is running, QEMU is a user program which has access to a number of local resources like partitions, files, network cards". A program with access to disks and PCI needs root, and the decision is defensible. What changes is the arithmetic of the news: whoever breaks out of the guest lands straight on the user that owns the node, with no intermediate landing where your telemetry could watch them stumble.
And the directory it lands in does not belong to that node
Proxmox keeps its configuration in pmxcfs, which its documentation defines as "a database-driven file system for storing configuration files, replicated in real time to all cluster nodes using corosync". It is the /etc/pve directory you see on every node, and it is the same one on all of them. Inside sits a subdirectory with permissions of its own: "Files below the following paths are only accessible by root: /etc/pve/priv/" (and also /etc/pve/nodes/${NAME}/priv/). Precisely the user the escape just landed on.
The ten lines, as the documentation lists them
This is what that documentation enumerates in there, with the description it gives each file. The only thing we touched is expanding the prefix: the original table writes them as priv/authkey.key and here they carry the full path— and wrapping onto a second line the two descriptions that did not fit.
/etc/pve/priv/authkey.key Private key used by ticket system
/etc/pve/priv/authorized_keys SSH keys of cluster members for authentication
/etc/pve/priv/ceph* Ceph authentication keys and associated capabilities
/etc/pve/priv/known_hosts SSH keys of the cluster members for verification
/etc/pve/priv/lock/* Lock files used by various services to ensure
safe cluster-wide operations
/etc/pve/priv/pve-root-ca.key Private key of cluster CA
/etc/pve/priv/shadow.cfg Shadow password file for PVE Realm users
/etc/pve/priv/storage/<STORAGE-ID>.pw
Contains the password of a storage in plain text
/etc/pve/priv/tfa.cfg Base64-encoded two-factor authentication configuration
/etc/pve/priv/token.cfg API token secrets of all tokensThe one of the ten that rotates itself
The first line has a quirk that changes how the whole list reads, and seeing it means leaving the documentation and going to the code. authkey.key is the key the ticket system uses to sign web and API sessions. Proxmox rotates it on its own: PVE::AccessControl carries two fixed constants, my $ticket_lifetime = 3600 * 2; # 2 hours and my $authkey_lifetime = 3600 * 24; # rotate every 24 hours, plus a rotate_authkey() function that fires by itself once the key expires. Of the ten files in that directory, nine are credential material and one, lock/*, are lock files with nothing to rotate. Of those nine, authkey.key is the only one you do not have to put in any procedure: it renews itself every 24 hours, with five minutes of grace for the previous key and tickets that live two hours, and the rotation fires when the system next needs to sign, not off a clock. The other eight still work tomorrow, and next month.
And none of those files belongs to the node the guest landed on. pmxcfs replicates them in real time to all of them. A compromised node is, by construction, the secrets directory of the entire cluster, whether you run three nodes or twelve, and it does not matter which one held the virtual machine that failed. What took us a whole post to spell out in terms of what somebody else's root on a hypervisor costs is visible here at a glance, in a documentation table that has been published for years.
The line that takes two readings
It is the eighth: "Contains the password of a storage in plain text". If your backup storage is a Proxmox Backup Server, that is the credential your cluster talks to it with. And the storage documentation puts two neighbours in that same directory: the encryption key, "saved in a file under /etc/pve/priv/storage/<STORAGE-ID>.enc", and the master public one, in .master.pem. The backup password and the key to decrypt the backups, same directory and same permission.
What that credential can do once somebody takes it we have already covered, and will not reprint: how delete permissions are split, and the backup token that cannot delete, are in Proxmox Protected is not a lock, from August, where we also said retention has to live on the backup server and not on the client; and the console credential that reached further than its name suggested was yesterday. What is not there, and is the only thing we add here, is the failure mode: if you trim the token but leave retention configured on the cluster's storage entry, the backup job will try to prune at the end and will finish with a permission error that same night. Moving retention comes before trimming the token, not after.
The deliverable: the rotation list, line by line
If the directory belongs to the cluster and not to the node, then the day a single node is declared compromised —by this escape, by a leaked credential, or by a disk that went out for repair without being wiped— you do not rotate a password: you rotate the whole list above. Writing that list costs an afternoon in the cold and a weekend in the heat. Each line has a cost of its own, and it is worth estimating beforehand:
- The Ceph material, which the table describes as "Ceph authentication keys and associated capabilities". In our judgement it is the most expensive line on the list: we wrote up what it really costs when we migrated cephx keys and found that rebooting the VM does not refresh the key. If your rotation plan assumes this is one command, your plan is mis-estimated.
- The cluster CA and the ticket-system key. Rotating the CA reissues every node's certificate and locks out, for a while, anything that had the old certificate pinned. The ticket one invalidates open sessions, which is what you want, but it is worth knowing what time of day you do it.
- Every API token secret. This is not a list anybody can produce from memory: each token you rotate is an integration that stops working until somebody updates it, and some were set up by a supplier who has left, or by a script that has been running on its own for years.
- The storage passwords and, if you use backup encryption, the key. There is a question here worth answering in the cold and in writing: if you rotate the encryption key, what happens to the older backups encrypted with the previous one? Because the answer decides whether your rotation is paperwork or a migration.
Failure is inevitable, an outage is a design decision. Whether a hypervisor ever has a guest-to-host escape is not up to you: they all have. What is up to you is how long it takes to know what has to change when it happens, and that gets written today, with no patch and no CVE, looking at a ten-line table.
What we are not claiming
- We are not claiming an exploitable flaw exists against your Proxmox. There is a researcher's statement and a company's public confirmation inside its own bounty programme, as reported by one outlet. None of that is a technical advisory, and this post uses it as an excuse to measure the radius, not as a diagnosis of your platform.
- We do not know whether the flaw is in the kernel or in userspace, which versions it reaches, or whether the microVM environment where it was found resembles yours. Anyone claiming today that their hypervisor is safe, and anyone claiming the opposite, are both making it up.
- That there is no patch for this one does not excuse you from the ones that have one. In August we wrote about two Linux kernel flaws with published patches, one a virtual-machine escape and one a container escape and about the detail that Proxmox does not ship Debian's kernel, which decides where your fix comes from. If you are behind on that, start there and not with this news.
- QEMU running as root is not a Proxmox defect and we do not present it as one. Their documentation explains why and the reason is sound. We bring it up because it changes the count of steps between the guest and the secrets directory.
- The paths and quotes come from the official Proxmox VE and Proxmox Backup Server documentation, consulted on 8 October 2026 against the HTML of the pages linked below. We have tested no escape and we do not go looking for exploitation detail. If your version differs, the source wins.
With a small cluster and the console to hand, your own people can write the rotation list in an afternoon. It gets harder when nobody remembers which API tokens are live, when the backup server was built by somebody who has left, or when the management network shares a VLAN with the users' machines because that is how the project started. Deciding what each credential and each segment reaches, and writing it down, is zero trust work; timing the recovery with the cost of that rotation counted in is disaster recovery work. We sell both, so read this with the conflict of interest up front. If your people already have the list written, close this tab. If reading the ten-line table made you think "I would not know where to start with that one", let us talk.
Sources
- The Register, "Security researcher claims they found KVM guest-host escape flaw", published Tuesday 6 October 2026 at 03:06 UTC. Source of the two public quotes, the sentence naming Proxmox among those relying on KVM, and the sentence about the 50,000 dollars, which is the bounty programme's ceiling and not a confirmed amount. It is a news outlet, not a vendor advisory.
- Documentation for Vercel Sandbox: the service's purpose, Firecracker microVM isolation and root access inside the box.
- Official Proxmox VE documentation: QEMU/KVM Virtual Machines (QEMU as a root process and as a user program with disk and PCI access), Proxmox Cluster File System (pmxcfs) (real-time replication to all nodes, the root-only access sentence and the table of the ten priv/ files with their descriptions, reproduced above) and Proxmox VE Storage (the .pw, .enc and .master.pem paths for Proxmox Backup Server storage).
- Source code of PVE::AccessControl (pve-access-control package), source of the two quoted constants and of the rotate_authkey() function. It is the evidence that authkey.key rotates itself every 24 hours; that is not in the user documentation, which is why you have to go to the code.
- Official Proxmox Backup Server documentation, User Management: the datastore roles and privileges, whose split we broke down at the time in the August post linked above. The pmxcfs quote about replication to all nodes we already used in the post about the network each node keeps, where it served a different purpose. Data checked on 8 October 2026.
Microsoft 365
ES 
CAT 
EN