| Urgent: GhostLock (CVE-2026-43499) on OpenVZ 7 Where is the patch for WebPros / SolusVM users? [message #53891] |
Fri, 10 July 2026 11:21  |
viadck
Messages: 5
Registered: January 2018
|
Junior Member |
|
|
Hello everyone,
The current situation regarding the GhostLock root exploit (CVE-2026-43499) has reached a critical bottleneck for hosting providers running production workloads on OpenVZ 7.
According to official ecosystem roadmaps, OpenVZ 7 is supposed to remain supported. Yet, we are currently facing a severe, host-breaking local privilege escalation vulnerability with no clear path to mitigation or patching for open-source OpenVZ users.
The Corporate & Licensing Trap
Let's look at the reality of the WebPros ecosystem:
1. Virtuozzo maintains OpenVZ.
2. WebPros owns Virtuozzo, as well as SolusVM, which is actively licensed as management software for KVM and OpenVZ VPS nodes.
3. Due to internal corporate partnerships, third-party tools like KernelCare do not support OpenVZ 7, pointing users directly to Virtuozzo's native ReadyKernel instead.
This has created an absolute trap. My production host nodes are fully up to date on disk, running the latest stable release: 3.10.0-1160.119.1.vz7.224.4. However, running readykernel info yields Loaded patches: 0. Why? Because WebPros/Virtuozzo gatekeeps the live patch repository behind licensing channels that SolusVM/OpenVZ customers are not even given an option to purchase or order in their portals.
SolusVM support is currently deflecting tickets by stating that OpenVZ 7 security coverage is uncertain and that it's a "vendor issue." WebPros is the vendor for both sides of this equation. You cannot license orchestration software for a virtualization tier, block third-party security vendors, and then completely abandon the community when a major exploit hits.
If anyone from Virtuozzo or WebPros engineering is monitoring this forum, we need an official kernel update pushed to the public repositories immediately, or the ReadyKernel patch channels opened up for this critical CVE.
Leaving paying ecosystem customers stranded with an active root exploit because of broken licensing workflows is unacceptable.
Kind regards!
|
|
|
|
|
|
|
|
| Re: Urgent: GhostLock (CVE-2026-43499) on OpenVZ 7 Where is the patch for WebPros / SolusVM users? [message #53894 is a reply to message #53893] |
Sun, 12 July 2026 11:44  |
dmc_dtc
Messages: 20
Registered: May 2014
Location: Serbia
|
Junior Member |
|
|
Yeah, yesterday i had same problem, you are left with error 403 when you try to click on attachments, but if you go to URL of attached file in browser and click enter in the address bar after url of attachment - the download start - In any case i've created github page so anyone can try
https://github.com/dmcdtc/openvz-cve-patch-2026
I am planning to make .rpms of kernel made form .src.rpm official one, i made one for CentOS7 yesterday and it seems to work, just the source of my OpenVZ kernel will probably be 119 version (src.rpm) and i will add this patch so i can get binary kernel files. Again, i will wait few days for official patch before i do this kind of work, in the meantime you can use this patch for some important server.
EDIT: ive posted kernel.spec patch and binary kernel releases build with that spec.. so basically you just need to rpm -i vzkernel-3.10.0-1160.119.1.vz7.224.4.custom.x86_64.rpm - just for security reasons it is probably safer to build it your self with my patch and spec to be sure no other files were modified..
>> dmc / dtc <<
[Updated on: Sun, 12 July 2026 15:51] Report message to a moderator |
|
|
|
|
|
| Re: Urgent: GhostLock (CVE-2026-43499) on OpenVZ 7 Where is the patch for WebPros / SolusVM users? [message #53897 is a reply to message #53896] |
Mon, 20 July 2026 17:21 |
dmc_dtc
Messages: 20
Registered: May 2014
Location: Serbia
|
Junior Member |
|
|
It is nice to hear some good news and that this project is not dead... Just the pace is too slow for 2026. As you are all aware there were dozens of kernel vulnerabilities over 20 updates! just last month, yes, many of them are not probably applicable to openVZ7 3.10 kernel but still - OpenVZ support is just too slow and non existent ATM - no one has also said anything about for example another very serious KVM escape bug - Januscape CVE-2026-53359 it is probably not exploitable by defauult since kvm_nesting is off but still, why not patch it... so yeah, even if they come up with this patch, we would need confirmation of them picking up the pace of future kernel patches, i am slowly moving toward KVM solutions but will probably still be a bit stuck with OpenVZ on 2 or 3 clients until i manage to escape
I've checked their bitbucket for kernel *1160.129.226 and see no patch except the ones in April so yeah, looking forward if it happens
>> dmc / dtc <<
[Updated on: Mon, 20 July 2026 17:22] Report message to a moderator |
|
|
|
|
|
| Re: Urgent: GhostLock (CVE-2026-43499) on OpenVZ 7 Where is the patch for WebPros / SolusVM users? [message #53899 is a reply to message #53898] |
Wed, 22 July 2026 13:00 |
dmc_dtc
Messages: 20
Registered: May 2014
Location: Serbia
|
Junior Member |
|
|
Agree, the pace is just too slow even if they deliver patch for Ghostlock ... from the time Ghostlock was unveiled until now there were already many other potential serious vulnerabilities, as I've said above, even if they deliver Ghostlock patch soon (at this moment i dont even believe it) .. they would need to keep up with the pace of new vulnerabilities in the future ... in any case i think i will patch my own kernel from now on until i totally finish migration from OpenVZ
>> dmc / dtc <<
|
|
|
|
|
|
| Re: Urgent: GhostLock (CVE-2026-43499) on OpenVZ 7 Where is the patch for WebPros / SolusVM users? [message #53901 is a reply to message #53900] |
Thu, 23 July 2026 09:32 |
HHawk
Messages: 42
Registered: September 2017
Location: Europe
|
Member |
|
|
It is deeply disappointing to see the current state of the OpenVZ project. Updates for OpenVZ 7 have become extremely scarce, while OpenVZ 9 still does not appear to be developing into a maintained and dependable successor. Much of the project now feels outdated or effectively abandoned.
The lack of visible action following the disclosure of GhostLock (CVE-2026-43499) in early July 2026 has made the situation even more concerning. Regardless of the exact exposure of individual OpenVZ kernels, long-standing users deserve timely communication, clear security guidance and evidence that the platform is still being actively maintained. Unfortunately, we have seen very little of that.
A relevant detail is that we operate two separate companies. One uses OpenVZ-based solutions, while the other uses commercial Virtuozzo products for customers who are prepared to pay more for that platform. Virtuozzo may not be aware that both environments ultimately belong to us.
It may be assumed that organisations still using OpenVZ will eventually migrate to the paid Virtuozzo platform. In our case, however, the opposite is happening. Trust must be earned and maintained before customers will consider investing further in a commercial product. After years of uncertainty, delayed development, limited communication and unfulfilled expectations surrounding OpenVZ, that trust has largely disappeared.
We have therefore already started migrating our infrastructure to Proxmox. This is not a decision we have taken lightly. We have been using OpenVZ for more than twenty years, and it has been an important part of our infrastructure for a very long time. It has been a great journey, but we can no longer continue relying on a platform whose future and security maintenance remain so unclear.
Virtuozzo may not consider the loss of our OpenVZ and commercial Virtuozzo deployments significant, but it matters to us. We are tired of repeatedly being left waiting, receiving little meaningful information and being given the impression that improvements are coming while very little actually changes.
It is genuinely unfortunate that our journey with OpenVZ and Virtuozzo has to end this way. However, given the current state of the project and the lack of confidence in its future, migrating to Proxmox has become the only responsible choice for our companies and our customers.
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
and apparently i was successful but still haven't tested it in production to see if every software that uses mutex works - but proof of concept from nebula no longer works and all tests show that all mutex related things works, so i think this should work.. of course, consider this no warranty and not 100% tested patch but it seems to work - use on your own responsibility - here is instruction how to compile your own kernel with GhockLock patched on OpenVZ 7 (Should work on vanilla CentOS 7 too)
