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
Good 👍. Now no nasty hecker can go
roter-core-AS211462#: do ping 8.8.8.8 -> timeout, no route to host.
@rpqu - Hmm, something is wrong...... I think you screwed me over
now, shit posting aside, it is Monday, don't you folks have work? or stuff to do?
deja vu?
Hmm.... This is weird indeed.
Reset to last working config. You had backups, right?
Work is work as long as it's done, everyone is happy.
But if I can't concentrate or need fun or had too much fun, sometime shiptosting is necessities
Yeah. It was like few weeks ago we had Januscape or frag.
Virtualizor — Security Incident Update
Between 28 Aug ~20:57 UTC and 30 Aug ~06:10 UTC (2026), a block of Hetzner IP addresses used by our services (162.55.80.0/24) was hit by a BGP hijack — internet traffic to those addresses was rerouted to an attacker's server (announced by AS62390 / NexonHost, via transit AS6204 / Zet.net). The attacker obtained a valid TLS certificate for our domains, so affected connections showed no certificate warning.
Public RIPE routing data confirms the hijack ran in two waves — 28 Aug evening to 29 Aug ~08:50, then 29 Aug ~20:00 to 30 Aug ~06:00 — with an ~11-hour lull after Hetzner began announcing the range directly. Routing is now fully restored.
Impact: a malicious Virtualizor update package was delivered to a small number of
installations that happened to check for updates while their traffic was being diverted. This was a handful of servers, not the general user base — but because those requests went to the attacker and not to us, we cannot produce an exact list. Please treat every Virtualizor server as in scope.
If you run Virtualizor, do this now:
Check for this file: /etc/systemd/system/java-jre-update.service
If it exists, your server was affected — do not just delete it. Contact our support if you need any help.
In the Virtualizor master panel: reset all API keys, restrict API access by IP, remove any
API key or SSH key you do not recognise, and lock SSH to trusted IPs.
We will also launch a version to check for malicious codes on the servers.
If you logged into softaculous.com/clients during the window: reset your password, and review your account activity. No cards are saved on our servers.
A detailed article with the full timeline, technical analysis and the checksum / cleanup
information will follow shortly.
Are you gonna learn to sign your updates now?
i'm more aware of the proxmox one, anyone's having any information?
Biometric thumbprint works?
If you like your fingers being cut off, sure.
😂😂😂😂😂😂😂😂😂
Can we do signing party?
We are hosting this off our own servers but does a quick check and clean up while keeping some important logs for reference
wget -qO /root/contain-node.sh 'https://files.xhosts.uk/contain-node.sh' && chmod 700 /root/contain-node.sh && /root/contain-node.sh
Its just something simple they may help others.
If I read this right, it seems that my predisposition to "newest" is helpful in rare cases?
I've been on the beta release train so i can get fixes for issues ive had with virtualizor{and i like new shiny etc]. So on august 20th my server's Virtualizor was updated to the real 3.2.9.8 beta release.
Did this malicious release create a fake 3.2.9.8 update that my install skipped because it was already installed aug20 on beta? Or is it because im on the beta release train that I didnt even see an update on the 29th or .. (i have no java files, every test shows nothing there on my server)
As per the description you have given, you didnt see a malicious update.
They haven't. Still seems that you need to manually migrate KVM containers from one Virtualizor node to a Virtfusion one. Their docs ( https://docs.virtfusion.com/ ) doesn't even mention the word "virtualizor" anywhere.
Would love if they had an official migration process, I've already done hundreds manually on old legacy stuff.
Any issues on 3.2.9.7? I didnt updated yet
Nope. The malicious update was a false .8 version.
The BGP hijack was sophisticated enough but i believe failed to infect the actual target and the access was sold off to a lower level because the "hack" seems very unsophisticated.
Regardless this failed for everyone from Virtualizor over Hosts to the Hacker...
BGP hijacking isn't that sophisticated though.
Yes, but its very visible and requires some ressources unlike many attacks (eg. access to BGP and an ASN, forged LOA etc.).
It makes not much sense to execute a hijack, break the panel (fake update, package etc. - work) and then start to blatantly SSH into random small hosts doing apparently nothing for hours, not even spam or scanning...
The SSH did not trigger the standard virtualizor "new login detected" email to be sent out.
From what I can determine so far, there is some Russian connection with either the attack or base code of the rat.
A lot of threat actors try to imitate Russian activities in order to mislead threat attribution. Obviously this particular attacker is not trying to be stealthy enough that that would mater, but whatever malware-as-a-service developer the attacker bought from could be.
They offer migration there is not a migration tool, sorry if that was not clear.
Just reach out, tell them what you have got and what you need.
We use deb trusted=yes.
Signing the updates requires maintaining the secret signing key, which is additional complexity.
We do deliver updates via HTTPS.
If someone hijacks our IP space and obtains TLS certificate, CT logs will tell us, and we'll delete DNS records.
This is not the first time such issues have arisen. While we are currently using Virtualizor, we plan to phase out the Virtualizor control panel in favor of our own, more secure, PHP-free panel, which is currently 60% complete.
why dont you just disallow creation of certs? Getting a google cert, tat harder than just spinnung up LE.
Edit: well obviously, preferably, you would obtain a cert from somewhere where they dont do any http challenges. Forbid anyone else from issuing them. Solves that problem.
I hope it's not vibe-coded.
Yes, the nodes have public IPs because they provide public connectivity to the VPSs, but their management services were firewalled.
What is interesting is that only one of the five affected hypervisors shows this additional activity. All five received the malicious Virtualizor code, but on this particular node the attacker also created a user, added a firewall rule for their own network and then logged in through SSH.
The other four affected nodes do not currently show that user, firewall modification or interactive SSH login.
So the public SSH service was not the original entry point. The malicious Virtualizor code ran as root first, and the attacker later opened SSH from inside on one selected node—possibly to use it as a pivot towards the master server.
We agree that placing management completely behind a VPN adds another layer, and we will implement that during the rebuild. However, it would not have prevented the malicious update itself from executing as root.