[Probably Solved] KVM Escape, publication. CVE-2026-64561, ZAPScape

P

proxnoci

Member
Jan 15, 2023
51
6
13
Last edited:
There are quite some differences (>10000) between the kernel config of the POC (5511) and Proxmox(13338) , so verifying which ones exactly are relevant is some work.
 
Hi folks, I wonder how a vulnerability declared 0day just a couple of days ago could be fixed months ago. Math's not mathing here. Either the reported vulnerability and zapscape are not the same or the guy discovered it got money for nothing. I don't believe much the latter is the case.
 
CVE‑2026‑64561 (ZAPScape) was fixed in proxmox-kernel-7.0.14-9-pve and proxmox-kernel-6.8.12-40-pve: https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331/post-865179
rulezz said:
Either the reported vulnerability and zapscape are not the same or the guy discovered it got money for nothing. I don't believe much the latter is the case.
Click to expand...
I'm not sure. The linked article doesn't mention a CVE or provide much other useful information. But yeah, if this is indeed about a zero-day vulnerability that has just been discovered and doesn't have a CVE yet, it can't really be ZAPScape because that was already fixed in August.
 
Last edited:
  • Like
Reactions: proxnoci
It was mentioned to me as a ZeroDay without CVE etc. It then is researching a stack of needles for a specific one, only to find it in the neighbors barn
Part of the problem is there are about 800 CVE's issued/updated, half of which are important/critical, daily.
I adjusted the header when i found the CVE, and other info.
Even IF updated months ago in the kernel, Ubuntu 22 (won't fix?), 24 and 26 (WIP) are still reported as un-fixed.
Proxmox is Ubuntu based hence the question here.

Oct 5 th was the agreed upon end of embargo, a normal procedure in responsible disclosure, 2-4 months delay of publication.
 
Last edited:
proxnoci said:
Part of the problem is there are about 800 CVE's issued/updated, half of which are important/critical, daily.
Click to expand...
Yeah, that's because the kernel project assigns a CVE to practically every bug they find, since bugs in the kernel almost always are security-related in some way, simply because they're in the kernel.
proxnoci said:
Oct 5 th was the agreed upon end of embargo, a normal procedure in responsible disclosure, 2-4 months delay of publication.
Click to expand...
Okay, just to be extra sure, this article *is* actually about ZAPScape, and no new zero-day KVM escape vulnerability was discovered on October 5, as the article's title suggests?
 
it's not that bad for the kernel there are no 800 CVE daily against the linux kernel, just 800 released every day across the board.

And no i am not 100% sure, embargo date happened to be yesterday. I modified the title for this insecurity.
 
  • Like
Reactions: proxuser77
Hmm, yeah, if I search for "KVM escape vulnerability" into Google's News tab and then look at other recent articles on the topic, like this one, for example: https://tech-insider.org/vercel-kvm-zero-day-vm-escape-sandbox-2026/, this might indeed be a new vulnerability for which no CVE has been assigned yet.

But either way, I guess there's not much else we can do but wait and see. Either nothing else comes up, in which case it was a false alarm, or a fix will be released eventually. As for mitigations, it's difficult without knowing any details, and taking everything offline just as a precaution probably isn't an option in most cases either. ;)
 
Last edited:
I still don't see where it comes from this vuln is Zapscape. POC for Zapscape was published 2 month ago, what embargo are you talking about? And there was Januscape even before, so it seems quite possible some new vulnerability was discovered after Zapscape
 
  • Like
Reactions: proxuser77
rulezz said:
I still don't see where it comes from this vuln is Zapscape. POC for Zapscape was published 2 month ago, what embargo are you talking about? And there was Januscape even before, so it seems quite possible some new vulnerability was discovered after Zapscape
Click to expand...
Yeah, after doing a bit of Googling as mentioned above, I also think this could potentially be a new vulnerability. In that case, the question now would be whether the claim actually holds true, i.e. whether this new vulnerability actually exists and can be exploited in a meaningful way.

And yes, if it turns out to be true, that would make it the third major KVM escape vulnerability this year. But again, I guess we just have to wait and see.
 
Last edited:
rulezz said:
does any workaround exist for older kernels?
Click to expand...
No. And even if a mitigation would exist: Any EOL kernel won't get any updates nonetheless so you will still be vulnerable to any other security issue. In the age of llm-assisted security research it's only a question of when not of if.
So: Updates your system, no way around it.
 
Last edited:
  • Like
Reactions: proxuser77
Johannes S said:
No. And even if a mitigation woukd exist: Any EOL kernel won't get any updates nonetheless so you will still be vulnerable to any other security issue. In the age of llm-assisted security research it's only a question of when not of if.
So: Updates your system, no way around it.
Click to expand...
well, even supported kernel won't guarantee you aren't vulnerable. Cases when new kernel versions introduced new vulnerabilities are known. Speaking of proxmox-kernel-7.0.14: fixed version is not in the enterprise repo yet. Furthermore, I see a lot of topics regarding various issues with it just in this forum, so I have to think twice and probably conduct some tests before upgrading
 
rulezz said:
well, even supported kernel won't guarantee you aren't vulnerable. Cases when new kernel versions introduced new vulnerabilities are known.
Click to expand...
Of course, there are no guarantees. There are almost certainly still many undiscovered or undisclosed vulnerabilities in the kernel, and new code can always potentially introduce new bugs and vulnerabilities. This is simply how software development has always worked, and it has never been a valid argument against patching or staying on EOL versions. Quite the opposite, in fact.

If you want to be as secure as possible, apply patches. Otherwise, you'd have to assess every vulnerability individually, evaluate its impact on your environment, and track and maintain any mitigations you implement. Given the current rate at which high-severity vulnerabilities are being discovered, I think that's hardly feasible. So, leave that to the experts and apply the patches they provide. ;)

And especially with this particular vulnerability, I wouldn't rely on any workarounds. I did a quick Google search, and it seems that applying the patch is the only sensible approach here:
 
Last edited:
  • Like
Reactions: Johannes S and UdoB
rulezz said:
well, even supported kernel won't guarantee you aren't vulnerable. Cases when new kernel versions introduced new vulnerabilities are known.
Click to expand...

Yes but at least you are not vulnerable to any already known and fixed issue. And new code not also introduces nugs but might ( by accident ) also fix a still unknown issue ny accident. In a previous job we closed non-reproducible bugs from older versions as "durch Entwicklungsfortschritt gelöst" / "fixed by progress of development". My point is that camping on an older version will always mean that you will have to deal with bugs not present in tge newest version.
 
  • Like
Reactions: proxuser77
You must log in or register to reply here.
Top Bottom
Back