Virtualizor has confirmed that a BGP route hijack allowed an attacker to deliver a malicious update to installations of its virtualization control panel. Traffic intended for Softaculous infrastructure was diverted between August 28, 2026 at 20:57 UTC and August 30 at approximately 06:10 UTC. During the active waves, diversion reached roughly 72% of the 368 peers observed by RIPE RIS.
This was not a theoretical warning. Virtualizor acknowledges that some installations downloaded the modified package. Affected providers documented changes to legitimate Virtualizor files, a root SSH key, an unauthorized account, systemd persistence and an interactive attacker session.
Immediate action: every Virtualizor operator should inspect their nodes, even without a manual update. Preserve evidence before deleting indicators or restarting services. If root compromise is confirmed, cleanup is not a substitute for rebuilding the hypervisor.
Virtualizor incident at a glance
| Data point | Confirmed information |
|---|---|
| Full window | August 28 20:57 UTC to August 30 ~06:10 UTC, about 33.3 hours |
| Active diversion | Two waves totaling about 22 hours, separated by an approximately 11-hour lull |
| Hijacked prefix | 162.55.80.0/24, Softaculous infrastructure hosted at Hetzner |
| Observed route | AS62390 (NexonHost), through AS6204 (Zet.net), retaining AS24940 (Hetzner) at the end of the path |
| RIPE RIS reach | 368 of 368 peers carried the hijacked route at some point |
| Peak during waves | Median 266 diverted peers, about 72% of the full 368-peer set |
| Time-weighted average | ~28% of all 368 peers and ~65% of peers carrying a /24 route |
| Confirmed impact | A malicious Virtualizor package reached a small but undetermined number of installations |
| Control failure | The update client did not cryptographically verify packages |
| Routing status | Restored; no diversion observed after August 30 at 06:10 UTC in the cited data |
How the BGP hijack worked
Hetzner normally announced the broader 162.55.0.0/16 block. The attacker announced the more specific 162.55.80.0/24. BGP generally prefers the most specific route, so networks accepting that announcement sent traffic for those addresses toward the attacker.
The first wave ran from approximately 20:57 UTC on August 28 until 08:50 UTC on August 29, when Hetzner began directly announcing the /24. After an approximately eleven-hour lull, the unauthorized announcement returned near 20:00 UTC and continued until around 06:00 UTC on August 30.
Virtualizor reconstructed the event with RIPE BGPlay and RIPE RIS. It counted roughly 10,600 withdrawals. The route was therefore intermittent: a server received malware only if an update check landed during a diverted interval and completed.
Why HTTPS did not stop it
The impostor server obtained a technically valid Let’s Encrypt TLS certificate because automated domain validation was also routed through the hijack. Affected clients saw no certificate warning. Names included virtualizor.com, api.virtualizor.com and files.virtualizor.com.
Virtualizor also warns that logins to softaculous.com/clients during the window may have reached the attacker. Users active in that period should change their client-area password, review account activity and regenerate API keys.
The critical control gap: unsigned updates
Virtualizor states that its update clients did not yet cryptographically verify update packages. TLS secured a connection to the destination selected by routing, but it did not independently prove that the downloaded artifact was an authentic vendor release.
HTTPS protects transport. Artifact signatures protect origin and integrity even when routing, DNS or a mirror fails. Without that second control, the malicious response could be accepted as an update.
Real-world scope: confirmed versus unknown
Virtualizor describes a handful of affected servers but cannot provide a definitive list because malicious responses never reached its logs. A small confirmed count is not proof that every other node is clean.
On LowEndTalk, one provider reported matching changes on 5 of 34 hypervisors. On an examined node, the legitimate virt_check.php cron and creation of the attacker's SSH key occurred in the same second. The unauthorized proxyuser account then maintained an SSH session for about three hours and fifteen minutes.
There is currently no verified global total for providers, hypervisors or customer guests affected.
Fast diagnosis: check a Virtualizor node now
Use these commands for initial triage. Do not delete findings before preserving output, timestamps, hashes and suspicious files.
sudo test -e /etc/systemd/system/java-jre-update.service && echo "IOC: service found"
sudo systemctl status java-jre-update.service --no-pager
sudo getent passwd proxyuser
sudo pgrep -af 'java|jre-runtime|widdow'
sudo ss -tpna | grep -E '31\.77\.220\.138|:2025'
Virtualizor identifies /etc/systemd/system/java-jre-update.service as a known indicator. Providers reported additional IOC:
- Payload:
/usr/lib/jvm/.cache/jre-runtime.dat - SHA-256:
b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7 - Download:
cdn.nerat.cc/installer/widdow.jar - Account:
proxyuser - Observed connection:
31.77.220.138:2025 - Observed SSH source:
193.32.127.248 - Markers:
/usr/lib/jvm/.cache/.installedand/tmp/.vz_svc_done
Recover services on infrastructure you control
When rebuilding affected workloads, a VPS gives you network control, service isolation and external backup options.
sudo grep -RsnE 'cdn\.nerat\.cc|widdow\.jar|jre-runtime\.dat|proxyuser|AAAAC3NzaC1lZDI1NTE5AAAAIP13pPAm5jmInLQYD3XNb3HwrW4cAKDcphoT4kSKrnte' /usr/local/virtualizor /etc/systemd/system /root/.ssh 2>/dev/null
sudo stat /usr/local/virtualizor/_universal.php /usr/local/virtualizor/globals.php /usr/local/virtualizor/zzvirtservice
sudo sha256sum /usr/lib/jvm/.cache/jre-runtime.dat 2>/dev/null
A match is enough to isolate and escalate. No match does not prove cleanliness: interactive root access could have created other users, keys, jobs, services or binaries.
The official Virtualizor script and its limits
Virtualizor published virtualizor_security_scan.sh as a scan and cleanup utility. Review any root script before running it:
curl -fsSLO https://files.virtualizor.com/security/virtualizor_security_scan.sh
less virtualizor_security_scan.sh
sudo bash virtualizor_security_scan.sh
The script can find or remove known artifacts, but it cannot prove that no additional persistence exists. It does not restore trust in a system where malware executed as root.
What to do after a positive finding
- Isolate the node while preserving evidence.
- Do not restart
zzvirtservicebefore inspecting it. - Capture files, metadata, processes, connections, journals, authentication logs, cron, users and SSH keys.
- Rotate master/slave API keys, root/SSH, database, backup, billing and other reachable secrets from a clean system.
- Treat accessible data as potentially exposed and evaluate customer or regulatory notifications.
- Rebuild the hypervisor from known-clean media. Removing the JAR is not a forensic recovery.
- Review guests and restore only from backups whose date and integrity can be justified.
Actions even when the known service is absent
- Check whether the node performed an update check during the incident window.
- Regenerate Virtualizor and Softaculous API keys and restrict them to trusted addresses.
- Audit SSH keys, new users, cron, systemd, outbound connections and update logs.
- Place management panels and SSH behind a VPN, management network or allowlist.
- Change the Softaculous client password if used during the window and review payment activity when applicable.
Lessons for hosting operators
This incident joins three controls that should not be treated as one guarantee: BGP routing, TLS authentication and software integrity. RPKI/ROV and defensive announcements can reduce routing risk; Certificate Transparency can reveal unexpected certificates; signed updates provide an independent final check.
Operators also need separate management networks, off-host logs, an SSH-key inventory and tested hypervisor rebuild procedures. Guest backups are essential, but they do not replace recovery of the control plane.
Frequently asked questions
Was Virtualizor hacked?
Virtualizor confirms a BGP hijack delivered a malicious package to some installations. More precisely, this was a distribution-chain compromise enabled by route hijacking and missing cryptographic package verification.
Is every Virtualizor server infected?
No. Delivery required an update check during a diverted interval. However, the vendor cannot list every affected node and asks all operators to check.
Does the cleanup script guarantee recovery?
No. It addresses known IOC but cannot exclude additional persistence after root access.
Conclusion
This was more than a panel outage. An unauthorized route reached every RIPE RIS peer at some point, enabled a valid TLS certificate and placed a malicious update in front of clients that did not cryptographically verify packages. Confirmed infections remain limited, but the true total is unknown.
Check the IOC, preserve evidence and do not mistake quick cleanup for forensic recovery. To rebuild services on isolated infrastructure with root access, networking control and external backups, see Teramont VPS Hosting.
