Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]
Imustaskforhelp
90 points
29 comments
July 06, 2026
Related Discussions
Found 5 related stories in 734.1ms across 14,015 title embeddings via pgvector HNSW
- BadHost – CVE-2026-48710 Starlette Host-Header Auth Bypass ylk · 14 pts · May 26, 2026 · 61% similar
- CVE-2026-42511 Breakdown: RCE in FreeBSD mmsc · 14 pts · May 07, 2026 · 54% similar
- A CVE Dispute chmaynard · 12 pts · June 24, 2026 · 54% similar
- CVE-2026-31431: Copy Fail vs. rootless containers averi · 59 pts · May 05, 2026 · 53% similar
- OpenClaw privilege escalation vulnerability kykeonaut · 303 pts · April 03, 2026 · 53% similar
Discussion Highlights (7 comments)
br0ceph
"If you operate an x86 KVM host that accepts multi-tenant guests and supports nested virtualization, or use an instance on top of one" does this mean that you must have nested virtualization enabled to br vulnerable. does disabling this feature in the host os or bios, make you immune to this bug?
rvz
The full write up is here: [0]. This is a very nasty vulnerability and risks any service that uses and allows nested x86 virtualization features at risk. Including those running VMs as a service. > Running the PoC inside a guest VM can trigger a host kernel panic. A full escape exploit that works in a controlled environment also exists, but it is not released at this time and is planned to be released in the very distant future. The first commit that introduced this vulnerability was in 2010. [1] So it was undiscovered for 16 years until now [2]. It was only a matter of time that a vulnerability in KVM would appear. This one is really not good as it is the first KVM guest-to-host exploit working on both AMD and Intel. [0] https://github.com/V4bel/Januscape/blob/main/assets/write-up... [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
TZubiri
hey, here's a good rule of thumb. If you share resources, that reduces costs, but increases security risks. choose whether to share a filesystem, an OS, a kernel, hardware, or just use a dedicated server. The economics of sharing resources are all in a tiny sliver of the budget spectrum, the shoestring budget range : 0-1$/mo: serverless 1$-5$/mo containers 5$-200$/mo Virtual Machine(s) 200$-1Billion$/month , at least one dedicated server So if your hourly is worth anywhere upwards of 5$/hr, and your project has any semblance of seriousness, just use a dedicated server, and avoid a whole class of LPE vulnerabilities just to save some $. Businesses have expenses, let's stop pretending that all of these non dedicated server infrastructures are serious. Shell out 200$/month or stick to hobby status. No, I don't sell dedicated servers, but I should
rballpug
KVM, or x86 identified mail validation.
codedokode
> LPE: On distributions such as RHEL, /dev/kvm is world-writable (0666), so an unprivileged user can also use this vulnerability as a reliable LPE to gain root. Why on Linux device files are accessible by untrusted applications?
trebligdivad
Nested virt on x86 is curiously painful; you'd kind of think each layer would be isolated, so that the L0 (hardware) would only have to worry about it's VM (L1), and L1 would have to worry about it's VM (L2); but nope - the L0 top level hypervisor sees faults from the L2 and has to figure out that they are actually L2 not L0. IMHO the extra complexity (and historical flakiness of it) - makes me say that enabling nesting is a bad idea for public VM hosts.
CoastalCoder
Some of the comments here talk about the risk this poses for multi tenant vm providers. Wouldn't this also be a risk for people using VMs to sandbox untrusted code running on trusted hosts?