Virtualizor BGP Hijack Delivered Malicious Updates to Hosting Servers
Unauthorized route diversion targeted Virtualizor update traffic
Virtualizor said attackers used an unauthorized Border Gateway Protocol (BGP) route announcement to divert Softaculous traffic and deliver a malicious update package to some Virtualizor installations. The diversion ran from approximately 20:57 UTC on August 28 to 06:10 UTC on August 30. Virtualizor released Patch 9 and a Security Analyzer on September 1, but said every operator should inspect its servers because it has no definitive list of affected installations or affected-version range.
A hosting-provider account, AlbaHost, reported that five of 34 Virtualizor hypervisor nodes it examined contained the malicious modifications. The provider said injected commands appeared in three legitimate Virtualizor files and were later run by a root cron job. The attacker code added an attacker-controlled key to the root account, installed Java 17 if required, downloaded a Java payload and executed it as root.
Valid certificate and unsigned packages enabled the delivery chain
Virtualizor said traffic for Softaculous services was redirected to an attacker-operated server during the route diversion. The attacker obtained a valid Let's Encrypt certificate within that window, so connections through the server did not show a certificate warning. An installation checking for updates while its traffic was diverted could receive the modified package.
The update client did not perform cryptographic package verification and therefore did not reject the package on that basis. Virtualizor said package signing remained future work as of September 2. Its incident advisory describes the Patch 9 release as Virtualizor 3.2.9.9, while the release note calls it Virtualizor 3.2.9 in the release-candidate and stable branches.
Persistence indicators require host-level investigation
AlbaHost said the payload established persistence through a systemd service and created an unauthorized account named proxyuser. Its logs recorded a successful password-based SSH login to that account from 193.32.127[.]248. The provider said it had not confirmed modification of customer virtual private servers in its reviewed environment and had not independently confirmed a database export.
Virtualizor's scanner checks for the systemd unit /etc/systemd/system/java-jre-update.service, the payload at /usr/lib/jvm/.cache/jre-runtime.dat, altered core files and associated domains, keys and marker files. The vendor advised operators to preserve evidence and contact support before remediating a positive host. It also stressed that scanner containment addresses known indicators rather than restoring full host trust.
Operators should rotate credentials and restore trusted systems
Virtualizor advised operators to run the official scanner, rotate all Virtualizor API keys, limit API and SSH access to trusted IP addresses, and audit SSH keys, accounts, cron jobs, scheduled tasks and outbound connections. Altered core files require restoration from known-good content or reinstallation. AlbaHost said a clean rebuild is the only reliable long-term remediation for a host with confirmed root compromise.
Client-area users who logged in or entered payment details during the incident window should reset their client-area password, change reused passwords and review account activity and card statements. Organizations running Virtualizor should treat update-path integrity as an operational dependency: investigate every host that checked for updates during the window, rotate exposed credentials and rebuild systems whose root trust cannot be established.