URGENT: Virtualizor Compromised (31st AUG)

Comments

• forest Member

  12:34AM

  @rpqu said:
  fuck

  Thanked by 5rpqu zejjnt s0n1c BasToTheMax Nekopara
• systemfreaks Member, Patron Provider

  12:38AM

  I stopped using virtualizor many years ago, i don't think anyone should use them commercially
• yoursunny Member, IPv6 Advocate

  12:39AM

  List of our providers that use Virtualizor:

  • @DigiRDP
  • @EvolutionHost
  • @Lampard
  • @Hosteroid
  • @HostDoc

  Thanked by 1zejjnt
• backtogeek Member, Host Rep

  12:45AM edited 12:46AM

  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.

  Thanked by 7forest bugabuga Gravely Arirang rpqu s0n1c BasToTheMax
• MannDude Patron Provider, Veteran

  12:54AM

  @backtogeek said:
  Even more crazy when you consider VirtFusion offer migration services.

  Since when?
• georgedatacenter Member, Host Rep

  12:54AM

  fucking Virtualizor

  Thanked by 2bugabuga forest
• rpqu Member

  1:26AM

  Fuck
• Obelous Member

  1:33AM

  Is there a statement from Virtualizor?
• stupidgenius Member

  2:54AM

  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

  Thanked by 1rpqu
• reikuzan Member

  3:35AM

  Here we go again. . .
• Jamie_DreamIT Member, Host Rep

  3:50AM

  Update:

  • Virtualizor's update server was 100% compromised
  • Another host has confirmed the same compromise as us.
  • Virtualizor are still investigating, no updates from them

  Thanked by 1rpqu
• Jamie_DreamIT Member, Host Rep

  3:52AM edited 3:52AM

  If you're a host that has been compromised, please DM me your Slack email and we can collaborate and work together.
• trumvps Member, Patron Provider

  4:02AM

  Promox is also being hacked. Check it before you lose all your data.

  Thanked by 2JasonM rpqu
• Obelous Member

  4:03AM edited 4:06AM

  @Jamie_DreamIT said: Virtualizor's update server was 100% compromised
  Another host has confirmed the same compromise as us.
  Virtualizor are still investigating, no updates from them

  So Virtualizor themselves haven't confirmed it?

  And what were the range(s) that got hijacked?
• Jamie_DreamIT Member, Host Rep

  4:07AM

  @trumvps said: Promox is also being hacked. Check it before you lose all your data.

  Can confirm we're not using Proxmox

  @Jamie_DreamIT said: their BGP hijack a few days

  This may not be true according to our internal reports
• K4Y5 Member

  4:09AM

  Virtualizor is a POS PHP based cesspool. Condolences to those that use it commercially and were affected by this.
• servers_guru Member, Patron Provider

  4:24AM

  @trumvps said:
  Promox is also being hacked. Check it before you lose all your data.

  More info about this?

  Thanked by 3tentor rpqu oloke
• bakekok Member

  4:27AM

  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.service is actually executing/calling (C2 IP / domain / reverse shell).

  Time to lock down all master/slave nodes and audit systemd units.
• JasonM Member

  4:27AM

  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.

  Thanked by 6BasToTheMax tentor MannDude sh97 DP rpqu
• AlbaHost Member, Patron Provider

  4:32AM edited 5:21AM

  @bakekok said:
  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.service is actually executing/calling (C2 IP / domain / reverse shell).

  Time to lock down all master/slave nodes and audit systemd units.

  We can confirm that 5 of our 34 Virtualizor hypervisor nodes contained the same malicious modifications described in this thread. This was a root-level host compromise, not merely unauthorised access to a Virtualizor panel account.

  How the compromise was triggered

  On the affected nodes, malicious commands had been inserted directly into legitimate Virtualizor files:

  • /usr/local/virtualizor/_universal.php
  • /usr/local/virtualizor/globals.php
  • /usr/local/virtualizor/zzvirtservice

  The PHP files contained injected @exec() commands. The zzvirtservice startup script contained a similar payload inside its start function.

  The injected code performed the following actions as root:

  1. Added an attacker-controlled key to /root/.ssh/authorized_keys.

  2. Installed Java 17 if Java was not already installed.

  3. Downloaded widdow.jar from:

     https://cdn.nerat.cc/installer/widdow.jar

  4. Executed the JAR as root.

  5. Removed the original /tmp/widdow.jar download.

  6. Created additional persistence, a systemd service and a local user account.

  The normal Virtualizor root cron job executed:

  /usr/local/emps/bin/php /usr/local/virtualizor/scripts/virt_check.php

  On one examined node, this ran at 2026-08-29 22:23:01 CEST. In the same second, the malicious root SSH key was created. This strongly indicates that the initial malicious execution occurred through the modified Virtualizor files—not through an SSH login.

  Timeline from one affected node

  • 22:23:01 – Virtualizor virt_check.php started as root.
  • 22:23:01 – /root/.ssh/authorized_keys was created.
  • 22:23:11 – systemd configuration was reloaded.
  • 22:23:29–30 – Java 17 and its dependencies were installed through DNF.
  • 22:23:34 – malicious java-jre-update.service started.
  • 22:23:35 – malware installation marker created.
  • 22:24:01 – Virtualizor virt_check.php completed.
  • 22:32:30 – unauthorised user proxyuser and its home directory were created.
  • 22:33:56 – successful password SSH login as proxyuser from 193.32.127.248.
  • 2026-08-30 01:49:23 – the proxyuser SSH session ended.

  That unauthorised SSH session remained open for approximately 3 hours and 15 minutes.

  There was no logged use of the injected root SSH key on the inspected node. However, the key allowed passwordless root access and must be considered a fully functional backdoor.

  Malicious systemd service

  Service name:

  java-jre-update.service

  Description:

  Java Runtime Environment Update Service

  Command:

  java -Xmx128M -jar /usr/lib/jvm/.cache/jre-runtime.dat

  Payload location:

  /usr/lib/jvm/.cache/jre-runtime.dat

  SHA-256:

  b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7

  The service used Restart=always. On the examined system, the service file had already been removed while systemd still had the old configuration loaded and the Java process remained active.

  The payload was approximately 13.5 MB.

  Network indicator

  We captured the Java process maintaining an established connection to:

  31.77.220.138:2025

  The connection disappeared after the malicious Java process was stopped.

  SSH key indicator

  Attacker public key:

  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP13pPAm5jmInLQYD3XNb3HwrW4cAKDcphoT4kSKrnte

  Fingerprint:

  SHA256:YQmy1hKF1h5cdJLxlZ5EScNoxe/UDWahjsWuQw2ERi8

  Additional indicators

  • Domain: cdn.nerat.cc
  • Download path: /installer/widdow.jar
  • Temporary filename: /tmp/widdow.jar
  • Installed payload: /usr/lib/jvm/.cache/jre-runtime.dat
  • Installation marker: /usr/lib/jvm/.cache/.installed
  • Systemd service: java-jre-update.service
  • Unauthorised account: proxyuser
  • SSH source: 193.32.127.248
  • Java connection: 31.77.220.138:2025
  • One-time marker used by the modified startup script: /tmp/.vz_svc_done

  Current impact assessment

  We identified these indicators on 5 of our 34 Virtualizor hypervisors. We are continuing to examine every node because the absence of the Java process alone does not prove that a system is clean.

  At the time of writing:

  • We have no confirmed evidence that individual customer VPS instances were modified.
  • We have not yet independently confirmed a MySQL database export from our environment.
  • Another affected provider has reported indications that its MySQL database may have been exported.
  • Because the attackers obtained root-level access, we must treat all information accessible from the affected hosts as potentially exposed.
  • The unauthorised proxyuser session means the attacker had interactive access after the automated infection.

  Actions taken

  We have been isolating the affected nodes and have:

  • Stopped the malicious Java processes and network connections.
  • Quarantined the payloads for forensic analysis.
  • Removed or disabled the malicious systemd persistence.
  • Removed the attacker SSH key.
  • Locked the unauthorised proxyuser account.
  • Reset Virtualizor API credentials on the master and slave nodes.
  • Searched all 34 hypervisors for the same files, keys, accounts, services, hashes, domains and network indicators.
  • Begun reviewing SSH, system, process, database and network logs for possible data transfer.
  • Started notifying customers and requiring precautionary password changes.

  Because root access was obtained, simply deleting the identified files cannot establish that an affected host is trustworthy. A clean rebuild is the only reliable long-term remediation.

  Customer precautions

  We are advising all customers to:

  • Change their customer account and control-panel passwords.
  • Change root or administrator passwords on their VPS instances.
  • Review all authorized_keys files for unfamiliar entries.
  • Replace application, database, email, API and backup credentials.
  • Change reused passwords on other services.
  • Enable two-factor authentication wherever available.

  Quick checks for other Virtualizor operators

  Before deleting anything, preserve copies, metadata and hashes for investigation.

  Search the Virtualizor installation for the known injection:

  grep -RsnE 'cdn\.nerat\.cc|widdow\.jar|jre-runtime\.dat|AAAAC3NzaC1lZDI1NTE5AAAAIP13pPAm5jmInLQYD3XNb3HwrW4cAKDcphoT4kSKrnte' \
  /usr/local/virtualizor /etc/systemd/system /root/.ssh 2>/dev/null
  

  Check the service, process, account and connection:

  systemctl status java-jre-update.service --no-pager
  pgrep -af 'java|jre-runtime|widdow'
  getent passwd proxyuser
  ss -tpna | grep -E '31\.77\.220\.138|:2025'
  

  Check the payload hash:

  sha256sum /usr/lib/jvm/.cache/jre-runtime.dat 2>/dev/null
  

  Do not restart Virtualizor or zzvirtservice before checking the files. Restarting an infected startup script may execute the payload again.

  Virtualizor urgently needs to confirm:

  1. How these legitimate Virtualizor files were modified or distributed.
  2. Which versions, packages, mirrors or update periods were affected.
  3. Whether its update or distribution infrastructure was compromised.
  4. Official clean hashes for all Virtualizor files.
  5. Whether any database export functionality was used.
  6. A verified recovery and rebuild procedure.

  We will provide further information as our investigation continues. Other affected providers are welcome to compare timestamps, hashes, SSH indicators and destination addresses with us privately.

  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...

  EDITED, to include more detaiils.
  @virtualizor

  Thanked by 12Obelous Jamie_DreamIT s0n1c stupidgenius BasToTheMax iriska SpartanHost forest MannDude Gravely rpqu oloke
• Swiftnode Member, Patron Provider, LIR

  4:37AM

  @virtualizor
• forest Member

  4:49AM

  Let me guess, none of the hosts whose nodes were compromised will actually fully reinstall from scratch?
• Obelous Member

  4:51AM

  @AlbaHost said: Remote C2: 31.77.220.138:2025

  another thing to note, the malware gets that ip from resolving connect.ne-rat.xyz. I think nerat is a RAT SaaS, there's a panel hosted at web.ne-rat.xyz, so the malware isn't made specifically for this attack, so I don't think the attacker is very sophisticated.

  Thanked by 4forest AlbaHost BasToTheMax rpqu
• AlbaHost Member, Patron Provider

  5:35AM

  @Obelous said:

  @AlbaHost said: Remote C2: 31.77.220.138:2025

  another thing to note, the malware gets that ip from resolving connect.ne-rat.xyz. I think nerat is a RAT SaaS, there's a panel hosted at web.ne-rat.xyz, so the malware isn't made specifically for this attack, so I don't think the attacker is very sophisticated.

  Also this IP 31.77.220.138 is from QWINS LTD and upstream seems to be @dataforest maybe they can isolate that IP at least...

  Thanked by 1rpqu
• Obelous Member

  5:38AM

  @AlbaHost said:

  @Obelous said:

  @AlbaHost said: Remote C2: 31.77.220.138:2025

  another thing to note, the malware gets that ip from resolving connect.ne-rat.xyz. I think nerat is a RAT SaaS, there's a panel hosted at web.ne-rat.xyz, so the malware isn't made specifically for this attack, so I don't think the attacker is very sophisticated.

  Also this IP 31.77.220.138 is from QWINS LTD and upstream seems to be @dataforest maybe they can isolate that IP at least...

  Yeah, CDN is too. I reported both. Looks like the C2 doesn't respond anymore though, so I guess they acted.

  

  Thanked by 1AlbaHost
• Obelous Member

  5:39AM

  I reported the .cc domain too but it's nicenic so they probably won't do shit.

  Thanked by 1AlbaHost
• Radi Host Rep, Veteran

  5:52AM

  So only servers that got patch 3.2.9.8 got hacked so far?
• AspireHosting Member, Patron Provider

  5:54AM

  @forest said:
  Let me guess, none of the hosts whose nodes were compromised will actually fully reinstall from scratch?

  It would be best if they reinstall, because we never know what the attacker could have done

  Thanked by 1forest
• AlbaHost Member, Patron Provider

  5:56AM edited 6:05AM

  @Radi said:
  So only servers that got patch 3.2.9.8 got hacked so far?

  Not exactly. It appears that the 3.2.9.8 update notification was fake. All five affected servers reported that the update completed successfully, but their installed Virtualizor version remained 3.2.9.7 afterwards.
• Radi Host Rep, Veteran

  6:12AM edited 6:13AM

  *8 update was released on 20th August?