A Border Gateway Protocol (BGP) hijack redirected traffic intended for Softaculous infrastructure and was used to distribute a malicious update to some servers running the company’s Virtualizor hosting-management software. The incident illustrates how weaknesses in internet routing can become a software supply-chain attack when update clients rely on network transport security without independently verifying the package they install.

Virtualizor is used by hosting providers to administer virtual private server nodes across platforms including KVM, Xen, LXC, OpenVZ and Proxmox. A single management server may control hundreds of systems, so code executed at the hypervisor layer can place every guest on that host within the potential blast radius.

More-specific route redirected trusted domains

According to the incident details reported by Cyber Security News, the diversion began at approximately 20:57 UTC on August 28 and continued intermittently until 06:10 UTC on August 30. AS62390, associated with NexonHost, announced the 162.55.80.0/24 network through AS6204. That range belongs to a larger Hetzner allocation used by Softaculous update and billing systems.

Internet routers generally prefer a more-specific route. Hetzner was advertising the broader 162.55.0.0/16 range, allowing the unauthorized /24 announcement to attract traffic wherever it propagated. Routing telemetry showed that all 368 observed peers carried the rogue route at some point, with roughly 72 percent selecting it during active periods.

The campaign was not continuously stable. About 10,600 route withdrawals and an extended lull made the interception intermittent, which likely reduced the number of successful malicious update checks. Nevertheless, a diverted validation request allowed the attacker to obtain a legitimate Let’s Encrypt certificate covering virtualizor.com, api.virtualizor.com and files.virtualizor.com. As a result, users and software clients would not necessarily have seen a TLS warning.

Unsigned updates turned diversion into code execution

The pivotal weakness was the Virtualizor update process. The vendor said update clients did not cryptographically validate packages after download. Once the attacker controlled the route and presented a trusted certificate, a poisoned package could execute with root privileges on a server that checked for updates during the interception window.

Only a small number of installations are known to have received the payload. However, the attacker-controlled server would not appear in the vendor’s normal request logs, making the absence of a recorded download insufficient proof that a system is clean. There is currently no evidence that guest VPS instances were modified, but administrators should not treat that as a guarantee: control of a hypervisor creates a path to credentials, storage, networking and hosted workloads.

Checks operators should perform now

The reported indicator is the systemd unit /etc/systemd/system/java-jre-update.service. Softaculous advises customers who find it to contact the vendor rather than immediately deleting it, because preserving evidence can help determine what ran and what other changes followed.

• Review Virtualizor hosts for the named service and unexpected accounts, SSH keys, scheduled tasks or binaries.
• Rotate Virtualizor and Softaculous API keys, and reset client-area passwords used during the diversion window.
• Restrict management, SSH and API access to trusted administrative networks wherever possible.
• Examine guest and host telemetry for unusual authentication, process execution and outbound traffic.
• Preserve disk and memory evidence before remediation if compromise is suspected.

A broader update-security lesson

TLS protects a connection to the holder of a valid certificate, but it does not establish that a downloaded artifact was produced by the intended software publisher. Update systems need signed packages, pinned trust relationships where appropriate, rollback protection and verifiable release metadata. Routing monitoring and Route Origin Authorizations can further reduce exposure, although no single control removes every BGP risk.

Hosting providers should treat the event as an infrastructure compromise rather than an ordinary control-panel issue. Even organizations without a confirmed indicator should document their exposure window, validate update histories and rotate secrets proportionate to risk. The routing diversion has ended, but credentials or persistence established while it was active could survive long after normal routes were restored.