On August 31, Virtualizor disclosed that an attacker had redirected traffic meant for Softaculous infrastructure and delivered a malicious software update to some Virtualizor servers. The affected systems did not connect to an obviously suspicious domain. They reached the expected vendor domains over TLS, without a certificate warning, and received what appeared to be a legitimate update.
The route to the vendor had been diverted.
According to Virtualizor's incident notice, an unauthorized network announcement affected 162.55.80.0/24 between approximately 20:57 UTC on August 28 and 06:10 UTC on August 30, 2026. The address block hosted software update services as well as Softaculous customer and billing systems. The attacker obtained a technically valid TLS certificate for affected domains and served a modified Virtualizor package to installations whose update checks crossed the diverted route.
Virtualizor said only a small number of installations were known to be affected. It cannot produce a definitive list because requests intercepted by the attacker did not reach the vendor's logs. That leaves every operator with the same task: establish whether each Virtualizor hypervisor updated during the incident window, then determine whether the host can still be trusted.
The update channel crossed several trust boundaries
Border Gateway Protocol, or BGP, is how networks advertise which IP address ranges they can reach. Other networks use those advertisements to decide where internet traffic should go. In this incident, an unauthorized network announced a more specific route for address space used by Softaculous. Some traffic intended for the vendor followed that route to infrastructure controlled by the attacker.
HTTPS did not prevent the malicious update. TLS protected the connection that the client made, but the connection terminated at the attacker's server with a valid certificate. The update client also did not cryptographically verify the package itself, so it had no independent way to reject modified code.
Those two controls answer different questions. TLS helps authenticate an endpoint and protect data in transit. Package signing allows a client to verify that the software was authorized by the publisher and has not changed since it was signed. NIST's code-signing guidance describes those properties as source authentication and data integrity.
The distinction became decisive here. The attacker manipulated the network path and satisfied the TLS check. A valid signature tied to a separately protected publisher key could have given the update client another trust decision before installation.
Virtualizor acknowledged that its update clients did not yet perform cryptographic package verification. Its incident response included a plan to add code signing for packages.
Version inventory will not identify every exposed host
This is not a conventional vulnerability with a clean affected-version range. Receipt of the malicious package depended on timing and routing.
A server was at risk if it checked for updates while its traffic was diverted and completed the download. Two servers running the same Virtualizor release could therefore have different outcomes. One may have reached the legitimate update service. The other may have installed attacker-controlled code.
Start with a complete inventory of Virtualizor master and slave nodes. For each system, record:
- Hostname, management address, hosting location, and operational owner
- Virtualizor version and current patch level
- Automatic-update configuration
- Update checks and installations between August 28 at 20:57 UTC and August 30 at 06:10 UTC
- Egress path, DNS resolver, proxy, and any network telemetry retained for that period
- Endpoint, audit, authentication, and system logs available for review
Do not remove a host from scope only because the current version is correct. A compromised system may have received a malicious package and later installed a legitimate update. The later update does not remove an added SSH key, unauthorized account, systemd service, or separate payload.
The absence of an update record also needs context. Local logs may have been altered after root access. Compare Virtualizor records with package-manager history, filesystem timestamps, cron execution, network-flow data, proxy logs, and centralized telemetry where available.
Hunt for the known host changes
Virtualizor identified /etc/systemd/system/java-jre-update.service as a known indicator of compromise. The vendor advises operators not to simply delete the service if it is present. Preserve evidence and contact the vendor before remediation.
A firsthand report from hosting provider AlbaHost adds useful detail. AlbaHost reported finding malicious modifications on 5 of 34 examined Virtualizor hypervisors. The provider said commands had been inserted into these legitimate files:
/usr/local/virtualizor/_universal.php/usr/local/virtualizor/globals.php/usr/local/virtualizor/zzvirtservice
On one affected node, Virtualizor's normal root cron activity executed the modified code. The code added an attacker-controlled key to root's authorized_keys, installed Java 17 when needed, downloaded a Java payload, and established persistence through the java-jre-update.service systemd unit. An unauthorized account named proxyuser was later used for an interactive SSH session.
Published indicators also include the payload path /usr/lib/jvm/.cache/jre-runtime.dat, the marker /usr/lib/jvm/.cache/.installed, the temporary path /tmp/widdow.jar, and the SHA-256 hash b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7. The Hacker News compiled the reported host and network indicators, including attacker domains, an SSH key, and observed IP addresses.
Use those indicators as pivots, not as a complete definition of compromise. A missing service file is not enough to clear a server. AlbaHost observed a case where the service file had been removed while systemd retained the loaded configuration and the Java process continued running.
Review the broader host state:
- Root and administrative users' SSH keys, including creation and modification times
- New local accounts, changed groups, and unexpected password authentication
- Loaded and enabled systemd units, including units whose files are now absent
- Root cron jobs and changes to Virtualizor scripts
- Java processes, unfamiliar executables, and outbound connections
- Package-manager activity, especially unexpected Java installation
- Access to Virtualizor databases, backups, API credentials, and customer records
- Administrative actions against guest systems during and after the incident window
Centralized logs deserve more weight than records stored only on the hypervisor. Once an attacker has root, local logs and timestamps may be incomplete or manipulated.
Preserve evidence before running cleanup
Virtualizor published a security scanning and cleaning script, but collection should come before cleanup when compromise is suspected. Isolate the management interface and restrict outbound traffic as needed, then preserve the evidence required to understand the intrusion.
Capture the current process list, network connections, loaded systemd state, user and group records, SSH keys, cron configuration, shell histories where available, relevant Virtualizor files, package history, and filesystem metadata. Retain Virtualizor, SSH, system, audit, database, firewall, flow, and identity logs. Record the server time, time zone, and each response action.
Validate response scripts through a separate trusted channel before running them on a potentially compromised host. Keep a copy of the script and its hash in the case record. The purpose is not procedural formality. A cleanup action can stop a process, remove a file, or change timestamps that responders need to reconstruct the event.
If the server is actively communicating with attacker infrastructure, containment cannot wait for perfect evidence. Disconnect or filter the hostile path, preserve what remains, and document what the team changed.
Root access changes the recovery decision
The malicious update executed through software that already operated with high privilege. AlbaHost described the result as root-level host compromise and concluded that deleting the identified files could not restore trust. The provider began isolating affected nodes, quarantining payloads, removing persistence, resetting API credentials, reviewing logs, notifying customers, and planning clean rebuilds.
That is the correct recovery frame. A confirmed backdoor on a hypervisor is not a malware-cleanup ticket. Rebuild the host from known-good installation media and trusted configuration, then restore workloads through a controlled process. Validate the replacement system before returning it to service.
Credential work should include more than the visible unauthorized account. Virtualizor recommends resetting all API keys, restricting API access to trusted IP addresses, and removing unrecognized keys. Operators should also review root credentials, SSH keys, database credentials, backup access, automation secrets, support credentials, monitoring accounts, and tokens available from the host.
Scope customer and guest impact based on evidence. AlbaHost had not confirmed modification of individual customer VPS instances in its published assessment, but root access to the hypervisor gave the attacker a position from which host data and management functions could be reached. Review guest administration events, console access, snapshots, image changes, storage access, network configuration, and authentication activity before deciding that the incident stopped at the host layer.
Document uncertainty directly. If telemetry cannot show what happened during the exposure window, say so in the incident record and let that uncertainty influence rebuild, credential rotation, and notification decisions.
Treat privileged updates as security events
Infrastructure teams cannot directly prevent every upstream routing failure. They can reduce the chance that a routing event becomes silent code execution.
Require cryptographic verification for software and firmware updates that run with administrative or root privilege. Ask vendors whether update packages are signed, where signing keys are protected, whether clients fail closed on invalid signatures, and how key rotation or revocation works. A checksum downloaded from the same redirected server is not an independent integrity control.
Monitor the effects of updates as well as their completion status. A hypervisor update followed by a new root SSH key, Java installation, systemd service, local account, or unfamiliar outbound connection should create an investigation path. Maintenance windows are useful context, but they should not suppress every privileged change made during the window.
MSPs and hosting providers also need a repeatable vendor-incident intake process. The process should connect the advisory to affected assets, update timing, preserved evidence, customer scope, credential actions, rebuild status, and notification ownership. A vendor statement that only a handful of systems were affected does not resolve risk for an operator that cannot establish whether its servers were among them.
The immediate task is narrow: identify every Virtualizor node, review the August 28 to August 30 update window, preserve evidence, hunt for the published host changes, rotate exposed credentials, and rebuild confirmed root-compromised systems.
If your team finds the published indicators or cannot establish what occurred on a privileged host, CulperSec's Incident Response team can help preserve evidence, scope access, and build a defensible containment and recovery plan.
