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.
URGENT: Virtualizor Compromised (31st AUG)
Jamie_DreamIT
Member, Host Rep
in Providers
Virtualizor has been compromised, their BGP hijack a few days ago seems to have a deployed a malicious package.
- RESET/LIMIT ALL API CREDENTIALS IN THE VIRT MASTER PANEL BY IP
- CHECK FOR SUSPICIOUS KEYS AND ENSURE SSH IS LOCKED DOWN
- CHECK IF THIS FILE EXISTS ( /etc/systemd/system/java-jre-update.service )
If you're an affected host, NOC or provider and would want to work together, please DM me, we'll appreciate any assistance here.
Comms are being sent for existing customers, at this stage, we don't see evidence of VPS's being compromised.
Good luck to other providers out there.
Comments
I stopped using virtualizor many years ago, i don't think anyone should use them commercially
List of our providers that use Virtualizor:
I honestly cannot understand why anyone would even consider using virtualizor in 2026, it is literally paying to disadvantage your business in every conceivable way.
Bad support, bad practices, bad software, a complete and total mess of a UI, terrible UX, supports literally everything but badly in the most limited way possible, multiple security issues and about $3 cheaper than VirtFusion.
Even more crazy when you consider VirtFusion offer migration services.
Since when?
fucking Virtualizor
Fuck
Is there a statement from Virtualizor?
From my quick research providers that have advertised or listed Virtualizor on their site over the last 6 months, pinging for viability.
FYI
@DediRock
@SolidVPS
@SmokyHosts
@hostdare
@xHosts
@Fourplex
@rarecloud
@HostMayo
@hostnamaste
@LittleCreek
@HostSlick
@3K33
Here we go again. . .
Update:
If you're a host that has been compromised, please DM me your Slack email and we can collaborate and work together.
Promox is also being hacked. Check it before you lose all your data.
So Virtualizor themselves haven't confirmed it?
And what were the range(s) that got hijacked?
Can confirm we're not using Proxmox
This may not be true according to our internal reports
Virtualizor is a POS PHP based cesspool. Condolences to those that use it commercially and were affected by this.
More info about this?
Thanks for the heads up @Jamie_DreamIT.
Any more IoCs (Indicators of Compromise) discovered yet? Would be helpful if anyone can share the sha256 hash or what the
java-jre-update.serviceis actually executing/calling (C2 IP / domain / reverse shell).Time to lock down all master/slave nodes and audit systemd units.
I think with all these recent incidents which are rising we need a new topic category called "vulnerability" here on LET to find these posts eaiser.
I have confirmed the compromise and found the injected Virtualizor code responsible. This was not initially an SSH brute-force attack—the installed Virtualizor files themselves executed the malware as root.
Confirmed infected Virtualizor files:
/usr/local/virtualizor/_universal.php — malicious @exec() around line 450
/usr/local/virtualizor/globals.php — malicious @exec() around line 799
/usr/local/virtualizor/zzvirtservice — malicious code around line 27 inside the start) branch
The injected command performs the following:
Adds this root SSH key:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP13pPAm5jmInLQYD3XNb3HwrW4cAKDcphoT4kSKrnte
Fingerprint:
SHA256:YQmy1hKF1h5cdJLxlZ5EScNoxe/UDWahjsWuQw2ERi8
Installs Java using either:
apt-get install default-jre
or:
yum install -y java-17-openjdk
Downloads:
https://cdn.nerat.cc/installer/widdow.jar
to:
/tmp/widdow.jar
Executes it as root and then deletes the temporary JAR.
The malicious zzvirtservice code is gated by /tmp/.vz_svc_done, apparently as a one-time execution marker. The injected PHP code in _universal.php and globals.php can be triggered whenever those core files are loaded.
Confirmed payload:
Path: /usr/lib/jvm/.cache/jre-runtime.dat
Size: 13,540,023 bytes
SHA-256: b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7
Marker: /usr/lib/jvm/.cache/.installed
Marker contents: 1788035015105
Marker timestamp converts to 2026-08-29 22:23:35.105 CEST
Systemd persistence:
Unit: /etc/systemd/system/java-jre-update.service
Description: Java Runtime Environment Update Service
Restart policy: Restart=always
Command:
java -Xmx128M -jar /usr/lib/jvm/.cache/jre-runtime.dat
On inspection, the Java process was still active even though the service file had already been removed from disk; the enablement symlink remained.
Observed live C2 connection:
Infected node: *******
Remote C2: 31.77.220.138:2025
Process: Java payload
Connection state: established
The connection disappeared after killing the payload.
Confirmed timeline on the affected node, all times CEST:
22:23:01 — Virtualizor virt_check.php launched by root cron.
22:23:01 — /root/.ssh/authorized_keys created with the malicious ED25519 key.
22:23:30 — DNF transaction installed java-17-openjdk and dependencies.
22:23:34 — malicious Java service started.
22:23:35 — payload installation marker created.
22:24:01 — the relevant virt_check.php process ended.
22:32:30 — local account proxyuser was created with UID/GID 1002, /bin/bash, and a password.
22:33:56 — successful password SSH login to proxyuser from 193.32.127.248.
2026-08-30 01:49:23 — that SSH session closed, after approximately 3 hours 15 minutes.
There was no logged use of the malicious root SSH key, but the attacker definitely accessed SSH through the newly created proxyuser account. Its home contained only the default shell files, suggesting it may have been used primarily for SSH tunnelling/proxying.
The DNF history confirms transaction 21 was:
install -y java-17-openjdk
at 2026-08-29 22:23.
This proves the local execution path was malicious code injected into Virtualizor’s core files and subsequently triggered by ordinary Virtualizor/root-cron execution. The reported BGP hijack or compromised update infrastructure remains the likely upstream delivery mechanism, but I cannot independently prove that part from the host alone.
I have preserved the JAR, injected files, systemd data, hashes and relevant logs. I can provide the samples privately if useful. I am still scoping the remaining Virtualizor nodes; any node containing cdn.nerat.cc, widdow.jar, the SSH key above, or these injected @exec() commands should be considered fully root-compromised.
Also since virtualizor pushed updates 1-2 days ago which it was not generally from them, 5 out of 34 total hypervisors were affected by this as those 5 were updated but the rest failed for some reason as checked by cronjob/emails. Seems Virtualizor has no clue on what is going on and keep asking if we are using hetzner or ovh...
@virtualizor