BGP hijack diverted Softaculous update traffic during a 33-hour window
Between approximately August 28 at 20:57 UTC and August 30 at 06:10 UTC, update traffic for Softaculous services was rerouted to an attacker-operated server after an unauthorized Border Gateway Protocol (BGP) route announcement, Virtualizor reported. The first vendor-identified route announcement appeared at 20:57:30 UTC on August 28; The Hacker News confirmed that timing using RIPE Stat data. During the diversion window the attacker obtained a valid Let's Encrypt certificate, so connections routed through the malicious server displayed no certificate warnings to clients.
Malicious update modified Virtualizor files and built persistent root access
A hosting-provider account operating as AlbaHost on LowEndTalk reported that malicious commands were injected into three legitimate Virtualizor files and later executed by a root cron job. AlbaHost said five of its 34 examined Virtualizor hypervisors contained the same malicious modifications. The injected code added an attacker-controlled SSH key to the root account, installed Java 17 where the runtime was absent, downloaded a Java payload and executed it as root.
The Java payload established persistence through a systemd service, created an unauthorized account named proxyuser, and produced logs showing a successful password-based SSH login to that account from 193.32.127[.]248. In the provider's examined environment, AlbaHost said it had no confirmed modifications of customer virtual private servers and had not independently confirmed a database export.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildIndicators of compromise, command-and-control hosts, and artifacts
Virtualizor published a list of indicators of compromise (IoCs) that its Security Analyzer checks for and that operators should treat as known artifacts. Key entries include:
- Systemd unit: /etc/systemd/system/java-jre-update.service
- Installed payload: /usr/lib/jvm/.cache/jre-runtime.dat (SHA-256 b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7)
- Marker files: /usr/lib/jvm/.cache/.installed and /tmp/widdow.jar
- Altered core Virtualizor files: /usr/local/virtualizor/globals.php, /usr/local/virtualizor/_universal.php, /usr/local/virtualizor/zzvirtservice
- Injected strings and C2 domains: cdn[.]nerat[.]cc/installer/widdow.jar, connect[.]ne-rat[.]xyz, cdn[.]nerat[.]cc
- SSH-related artifacts: SSH key material AAAAC3NzaC1lZDI1NTE5AAAAIP13pPAm5jmInLQYD3XNb3HwrW4cAKDcphoT4kSKrnte, provider-reported account proxyuser, provider-reported SSH source 193.32.127[.]248, provider-reported IP and port 31.77.220[.]138:2025, provider-reported marker /tmp/.vz_svc_done, and SSH-key fingerprint SHA256:YQmy1hKF1h5cdJLxlZ5EScNoxe/UDWahjsWuQw2ERi8
Vendor response: Patch 9, Security Analyzer, and remaining work
Virtualizor released Patch 9 with a Security Analyzer on September 1. The release notes place the build as Virtualizor 3.2.9.9 in the incident advisory and as Virtualizor 3.2.9 (Release Candidate and Stable Branch) (Patch 9) in the release note. As of September 2, Virtualizor had not published a malicious-package filename or hash, an affected update-channel list, or a build that enforces cryptographic package signing; the vendor said package signing remains future work.
The vendor’s scanner script, whose SHA-256 was 73e74402b3a61c7bab289fc11347bd54c7fcdc2fa2e410f4c3de9d6cd7377d48 when checked on September 2, 2026, checks for the known artifacts and is designed to contain them. Virtualizor advises operators to contact support before remediating a positive host so evidence can be preserved; the scanner’s containment should be treated as containment of known indicators and further remediation performed to restore host trust.
What this means for Virtualizor operators, client-area users, and other Softaculous product operators
Virtualizor operators: The vendor advised checking every server because there is no definitive affected-version range or list of installations that received the malicious package. Operators should look for /etc/systemd/system/java-jre-update.service and, if present, preserve evidence and contact Virtualizor support. Other steps include rotating all Virtualizor API keys, restricting API access to trusted IP addresses, auditing unknown SSH keys and new users, reviewing scheduled tasks and outbound connections, restricting SSH to trusted IPs, and running the official scanner.
Client-area users who logged in or entered payment details during the incident window: Virtualizor advised resetting client-area passwords, changing passwords where reused, reviewing account activity, and reviewing card statements if payment details were entered. Client Center API users should regenerate keys and update them on their servers.
Operators of other Softaculous products: Virtualizor told operators to check Webuzo, Softaculous, Backuply, SitePad, and other product servers that performed an update check during the diversion window. The vendor had not identified a malicious package for those products and said its investigation remained open.
Remediation realities and final note
Virtualizor’s scanner can detect and contain known artifacts, but altered core Virtualizor files require restoration from known-good content or reinstallation. In environments with confirmed root compromise, the AlbaHost account reported that a clean rebuild is the only reliable long-term remediation. Virtualizor has not reported confirmed client-account or payment-data theft as of September 2.
Operators should treat this as a reminder that update channels and routing integrity can be exploited to deliver trusted-looking content: when an update client does not verify package signatures and a valid certificate is presented by an attacker-controlled host, a malicious update can appear legitimate. For Virtualizor users, that interplay of routing, TLS issuance and absent package signing is the proximate cause of the incident and the narrow set of actions the vendor has published are the immediate path to discovery and recovery.
