New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
There was a Virtualizor support security breach at that time, which resulted in any passwords shared with support being exposed. This is old news, and users were notified by email and instructed to change their passwords. As a general security practice, passwords should always be changed after a support issue is resolved. This incident is also why Virtualizor replaced the old system with the new built-in support feature within the Virtualizor panel itself. This case is separate to that.
Sounds about right honestly. This is pretty bad on both sides though.
That's scary - does that mean you share root credentials with a third party and don't revoke access again as soon as possible?
Please read it again.
It was a test environment, where we are trying some custom stuff before deploying to production.
It wasn't important for us, more important was how the attacker got admin credentials.
When we provide access to 3rd party companies that provides support for our software, we create additional accounts just for them and we delete after it's solved.
It seems this person (Radmin/Zilor_MP) is affiliated with both the telegram and discord server and the domain oldenvale.ru. He promoted the oldenvale server launch on the same day that domain was registered (2025-08-13) and the server version per his telegram announcement is also the same one listed on hotmc.ru:
https://t.me/radminZR7/505
There are plenty of potential classes of vulnerabilities that could be used to do this that would not fall under either of those. Virtualizer (and honestly, every alternative) is needlessly bloated and likely quite insecure.
All of this could have been prevented if there was even a modicum of control plane separation.
I understand these are two separate incidents. My point was to provide context, not to suggest the current attacks are caused by the old ticket system breach.
But this brings us back to the main question: if it's not a credential leak, then how are attackers getting into the admin panel now?
I've spent last hours searching for any technical details about this exploit. Checked security forums, CVE databases, even tried to find the original script that was used. Nothing concrete. No one seems to have actually reproduced the authentication bypass. As @SecNinja explained that the TTY authentication flow looks solid with htpasswd protection.
So what's the actual attack vector here? A 0-day in the panel authentication? Something else entirely?
Look, this is serious. Multiple hosting providers are affected, thousands of customers have lost data, and we still don't know how attackers are getting in. We need to communicate and work together on this. Pointing fingers or dismissing each other's theories won't help anyone.
If someone has actual technical details about how the breach happened, please share. We can't protect ourselves or our clients if we don't understand what we're protecting against.
I’m also trying to understand the situation. I would recommend the following are done:
• Enable 2FA authentication in Virtualizor Settings (Requires logging into each slave manually if done only on master)
• Disable terminal access from Master → Settings → Security on both the master panel and all nodes, then resync the nodes
• Enable IP restriction for Virtualizor login access
• Enable API IP restriction, allowing only your billing system’s IP address
• Disable unnecessary API key permissions (for example, terminal access) by unticking them
• Resync all nodes after making these changes
• Enable 2FA for SSH on all master and slaaves using PAM
• Ensure all passwords are stored and managed securely and changed if you provided them to support last couple of months and haven’t change them.
Thanks
Crești mare!
Noroc.
I don't think this is a 0-day. Real 0-days don't discriminate. If attackers had one, they'd scan every IP for port 4085 and nuke everyone, not just a few unlucky providers 😄
Did some digging through exploit databases and found absolutely nothing. Zero. Nada. 🤷
Maybe this vulnerability is not publicly known. Maybe Virtualizor did such a good damage control operation in making others keep silence, that itself has no idea what the vulnerability is either.
EDIT: forgot the gif.
My idea still stands. Even if it's a private exploit, attackers don't sit on 0-days and carefully pick targets. They exploit fast and wide before it gets patched. That's how the game works.
A few specific providers getting hit? That's a target list, not a vulnerability scan... Hopefully
)
Some vulnerabilities require privileges for successful exploitation, which in this case could mean that attacker must buy VPS first. Much harder to scale compared to scanning all exposed Virtualizor instances and sending some payload to all of them using cURL.
Do providers really give support staff Virtualizor login credentials?
If that's the case for all providers that have been affected then it's almost certainly from a databreach there.
@cu_olly referred to a such a security incident the softaculous had in 2025. Could be the from that same incident or another one.
Often companies get pwned by infostealer logs that get resold/leaked on forums. Could also explain the 2FA bypass since cookies are typically included.
Very standard stuff, there are literally thousands of employee credentials being sold every single week, there's even security products dedicated to tracking that stuff.
Hey @virtualizor @SecNinja check this out:
https://www.hudsonrock.com/search/domain/virtualizor.com
Total Compromised: 133 records
Last User Compromised: 37 days ago
https://www.hudsonrock.com/search/domain/softaculous.com
Total Compromised: 18,890 records
Last User Compromised: 3 days ago
Employees: 1,712 compromised employees
Last Employee Compromised: 8 days ago
Wheres that data from?
Employees: 1,712 compromised employees
lol? Watching porn every day in the office wanking and clicking the infected ads or how is that possible?
Hudson Rock has a huge database of hundreds of millions of records in plain text.
Probably freebies on forums, them buying up logs, etc.
Note also that many of these infostealers are MaaS, so all it would take is access to a single central C2 to get complete infostealer logs from thousands of threat actors.
E.g. RedLine was said to be responsible for like half of all infections globally.
But yeah I also wonder how they get some of their data. Sometimes the hackers even infect themselves and end up leaking their credentials/identity:
Regarding the quantity:
Initial access happens through something stupid like phishing, porn, cracked software, ... on an employee machine. Either personal or company machines.
Attackers then typically move laterally through insecure LAN setups, which is unfortunately often trivial in small companies.
Then they look for data and dump infostealers on all machines, maybe install ransomware, ...
This. Basically.
I recognized how massive of an undertaking it'd be to do this manually. A year or more ago we started using VirtFusion and encouraging self-migrations as we've basically dropped support for legacy VMs. Sadly there are still a ton on that platform but "moving everyone to VirtFusion" jumped closer to the top on my never ending to-do list in recent days.
Will start in WA and PA first, just waiting on some new hardware. The migration process hopefully won't require the end user to do anything but be patient.
It doesn't have to be a reliable 0day that works on all configurations. 0days can be highly conditional, only working on certain versions with certain non-default configurations or requiring specific combinations of software versions. Some other 0days may require user interaction for the exploit to be triggered. There are plenty of possibilities that lie between "no exploit, can't do shit" and "reliable pre-auth remote code execution that can pwn every Virtualizor installation".
That doesn't mean that this is a 0day, of course, just that you can't rule it out simply because it's not an insanely powerful one that can exploit any Virtualizor installation and because you didn't find it on public exploit databases.
Not true. While some attackers do that, hoarding 0days is ridiculously common, especially if it's not remotely exploitable (there are lots of hoarded kernel LPEs, for example). I doubt any script kiddie would hoard a real 0day, though.
Not everyone is eager to burn their 0day.
Buying a VM doesn't give you access to the Master server. KVM is isolated, and nobody runs VMs on the master node anyway.
What happened here is attackers had access to the Virtualizor panel itself, then used the terminal feature to reach all slave nodes. That's panel access, not a VM escape.
If I had to guess... probably a vulnerability on a payload communication between servers. Just a wild idea.
Because, if the WHMCS module is audited and Virtualizor is audited and no flaws are found, probably may not be something in one or the other... but in the middle.
I'm intrigued.
I think most people are at this point.
Just received this in a private message from @virtualizor
Where has the hacker claimed they used any vulnerability in ColoCrossing or CloudCones case. ColoCrossing was having a breach because of the screenshots that leaked and unfortunately they didn't have an ip restriction on their panel for the Admin Panel side.
Whatever breaches that have happened and have come to the front is because of root passwords leaked during that time.
Ouiheberg got compromised for which we were blamed but their POC was not anything close to a POC and was an AI generated inaccurate POC. They obviously blamed and ghosted us.
We are not yet sure about CloudCone, and are awaiting details from them. The security terminal thing they mentioned seems to be inaccurate. We are not ruling out that the password was leaked in 2025 and their password was not updated or the hacker placed a backdoor then and used it now.
We will investigate and post, but please don't blame us if a host didn't have a firewall in place nor updated the root password since the 2025 leak
No idea why they're messaging me privately rather than communicating with their actual customers, but maybe they want me to read the forum for them... 🤷♀️
Also, all the providers who've been hacked recently didn't change their root passwords since the last hack, so don't blame them for their customer's incompetence 😬
For transparency, I just replied to them with the following....
I have never said anything about VM escape.
What I said is that some privileges could be required. When someone orders VPS they get account created in Virtualizor automatically. However, as for CloudCone case, if I understood correct all management of customers' VPS happen using one same shared account, which is controlled by CloudCone's own panel (acting as a middle proxy), yet attacker could still issue commands for Virtualizor over it (i.e. start/reboot VPS, and probably something else which has vulnerability).
hostslick is down since last night utc+7, when will the vps up again?
LowEndDetectives #LowEndDoakes
Looks like Lowendproviders have become lowenddoakes instead
Virtualizor right now
Just another dexter meme before I go.
I do think that the matter is very serious though and I think I am pretty serious but this time just wanted to lighten the mood on what is a very genuine issue.
Hope that the issue can get fixed most likely. When Cloudcone was hacked, I had thought that it couldn't be virtualizor because virtualizor was hacked then other providers would've come too .but now with further information. Virtualizor's the culprit from what I can tell.