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
Only if you have ticked for beta release in your virtualizor panel, otherwise they publish always earlier on their blog but live updates take place late i.e a week or two.
I am on *7 and ticked Stable, well now changed to "NEVER".
Let me guess #2, virtualizor doesn't know what PKI or signing things is?
Well if you had on Stable which is by default you will be better of to check your hypervisors as the fake update that pushed malware 1-2 days ago from virtualizor servers/mirrors was automatic update.
with these AI tools, everyone can become a vibe hacker in minutes...
Oh for sure. I didn't even believe for a moment that Virtualizor would be professional enough to sign releases.
OMG ! Would OVH be one of those affected ? have few VPS with them
@Chunkserve also use Virtualizor
@naranjatech use Virtualizor to.
And iHostArt.
Virtualizor makes slop panels look good
virtualizor got virtualizord.
We are aware of this.
We had been waiting on a reply from Virtualizor until about 30 minutes ago.
We had written a few quick bash scripts and these have been run on all servers.
One is a quick check and clean up script, while its not a failsafe, it cuts down the current risk
We had spent most of yesterday collecting and saving evidence.
We had fired off a large number of abuse reports while waiting on Virtualizor and did notice certain parts of the rat’s network become unreachable.
We are in talks with other companies to have the remaining parts at the very least suspended.
One advise I would give to other provides is to cycle your DB passwords on each slave.
We used a quick bash script to change the password and update the universal.php allowing it to only take a few seconds rather than it being a pain in the ass manual task.
We did not want to make a post until it had been confirmed by Virtualizor or draw a lot of attention if the attackers lurk on the forum.
Thanks for the mention. Right after I did a quick ansible script for rest of our Virtualizor nodes, that we still need to move in the future. The playbook looks incidators shared by @AlbaHost and @Jamie_DreamIT . I did not find anything here indicating we were compromised or targetted. I checked also virtualizor update log, and last "Server Update" task happened at July 31, 2026, 4:22 pm. Proactively, I ensured that auto updates are disabled and restricted virtualizor access for nearest future.
I also mailed virtualizor about more details of this incident.
Thank you for the awesome work, I really appreciate sharing these publicly.
Feels like near miss
@AlbaHost
Just a question, do the nodes have Public IP? From what you wrote I understand yes.
Now, don't take this personally, but why the heck would you let a node be on a public IP address rather then to have them on an internal LAN ( MNG VLAN ) that is accessible only via some sort of VPN/Security path? ) this does not guarantee 100% protection, but it does make the usual and simple hack much harder or more time consuming on the hacker end.
I really don't get this, I never did, exposing a bare metal node on the public net is like having a sign "come and fuq me".
Also, I think most learned by now, Software QC is close to none these days, so I would not bet/trust a software provider that he knows what he is doing.
Either way, hope you guys manage to isolate this as soon as possible.
Cheers!
Many host are like that. Maybe until the site admin made it a rule
There should be a tag on LET for providers that have gone through a very, very, very basic security audit. Like... not leaking L2 traffic, not able to hijack other IPs from other tenants, not exposing the node directly to the internet, and using reasonably up-to-date software.
It is a bad idea, it always was a bad idea, and it will always be a bad idea.
This is not the first time we see this. nor the last.
I get the fact that it is much more simple and easy to configure your nodes with a public ip address, yet, this is precisely the case where simple is not a good idea. ( unless you have something like a Palo-Alto/Fortinet/Check Point/Cisco or other in front of it - even then, bad idea
).
Back in 2013 when I took my MSFT training courses and exams, all of them started with "don't set a public IP address on a server unless it is absolutely necessary, and even then be sure to put 3 packs of condoms on it".
A decade later, same problem ( well sort of ).
I am not mocking anyone here, that was not the idea behind my reply, but some should really change the way they do internal traffic shaping, as nodes and their traffic should be LAN traffic not WAN/Public, VM traffic is Public traffic, but nodes defenetly not.
Then LET would be a very lonely place.
As much as I like your idea, regulations rarely have a good outcome, and in that case, I would want KYC on users here, deal ? so the effort of Providers compensates with the price. It would be a fair trade in my view.
Failure usually leads to improvements, so chill and wait it out.
Also, most of you guys here filter out BS pretty quickly, well, most of the times you even get it right ( I will underline Most Of the Times
).
What is wrong with PHP, remember, you can't call a CAR faulty if driver has no proper skills.
Virtfusion and hypervisor.io are built using PHP, so by that law, both are flawed ?
They always have.
If allowed I would be happy to share the basic bash script we have to do the major parts of the checks if this is also fine with site admins
Why wouldn't it? I reposted the script the Muppets used to "destroy" the cloudcone vms.
Speaking about vulnerabilities...
WHMCS 9.0.7 and WHMCS 8.13.6 are now available as important maintenance releases for the WHMCS 9.0 and 8.13 series.
These releases address a security vulnerability which if exploited can result in unauthenticated remote code execution. There are currently no known exploits in the wild, but details that the vulnerability exists are shared.
We strongly recommend that all self-managed WHMCS customers update to the latest available version for their release series without delay.
This never ends🥲
@DediRock
@host_c @forest Please make tutorial for these basic opsec.
If it was me, I would have told hosts to block
0.0.0.0/0Nop, it is becoming a weekly update as it seems.
, talk about QC control, I really have the feeling is is being vibe-coded by now.
roter-core-AS211462#: ip route 0.0.0.0 0.0.0.0 Null0 - done.
