A BGP Hijack Made Virtualizor Install Malware as an Update

Softaculous says an unauthorised Border Gateway Protocol announcement diverted traffic for 162.55.80.0/24 between 28 August at approximately 20:57 UTC and 30 August at approximately 06:10 UTC. That address block hosted the Virtualizor update endpoint as well as Softaculous client and billing services.

The result is an unusually complete supply-chain attack. The route looked valid to much of the internet, the certificate looked valid to clients and the update package arrived through the expected hostname. One missing control remained: Virtualizor clients did not cryptographically verify the package itself.

A more-specific route won the internet’s trust

The malicious route was announced by AS62390, identified by Softaculous as NexonHost, through transit provider AS6204. It advertised a /24 inside Hetzner’s legitimate 162.55.0.0/16 block.

Internet routing normally prefers the more-specific path. Networks that accepted the announcement therefore sent traffic for the affected addresses toward the attacker’s server even though the wider Hetzner route remained present.

Softaculous reconstructed two sustained waves of diversion using RIPE routing data. Across the full incident window, all 368 RIS collector peers carried the hijacked route at some point. During active waves, the vendor estimates that roughly 72 percent of the full peer set was diverted at peak.

The certificate warning never appeared

The attacker also obtained a valid Let’s Encrypt certificate for Softaculous domains, including virtualizor.com, api.virtualizor.com and files.virtualizor.com. Certificate-authority validation traffic followed the hijacked route too, allowing the attacker-controlled server to satisfy the automated domain-control check.

That matters because TLS answered the question it was designed to answer: did the server reached through this route control the domain at that moment? It did not prove that the network route was legitimate or that the update package had been signed by Softaculous.

This is the same strategic weakness seen in other update-channel incidents. BlackTree previously examined how attackers abused the Notepad++ updater and how FortiClient EMS delivered malware through a trusted patch workflow. The common failure is relying on transport trust after the package leaves the publisher.

Virtualizor installed the attacker’s package

Softaculous confirmed that a malicious Virtualizor package reached a small number of installations that checked for updates while their traffic was diverted. The vendor describes the affected population as a handful of servers, but it cannot produce a definitive victim list because the malicious requests terminated on infrastructure it did not control.

The known indicator is /etc/systemd/system/java-jre-update.service, together with an enabled or running java-jre-update service. Administrators who find it should preserve evidence and contact Virtualizor support before simply deleting the file.

No malicious update has been identified for Webuzo, Softaculous, Backuply, SitePad or the vendor’s other products. The investigation is continuing, so that statement should not be read as proof that traffic to those services could not have been intercepted.

What operators should do now

• Check every Virtualizor server for the java-jre-update.service indicator, including systems believed not to have updated during the incident.
• Run the vendor’s security scanner and escalate any positive result before remediation destroys useful evidence.
• Rotate Virtualizor API keys, remove unrecognised keys and restrict API access to trusted addresses.
• Review SSH keys, user accounts, cron jobs, scheduled tasks and unexpected outbound connections.
• Reset Softaculous client-area passwords and sessions used during the incident window. Review payment activity if card details were entered while traffic may have been diverted.
• Upgrade to the current Virtualizor release and verify which package-integrity controls are active.

Softaculous released Virtualizor 3.2.9.9 with additional scanning and cleanup support. The company says package signing is planned. Until cryptographic verification is enforced by the client, network and TLS controls cannot independently prove that an update came from the publisher.

The BlackTree view

This incident crossed three trust systems without defeating their cryptography. BGP accepted the more-specific route. Automated certificate validation accepted the server reached through that route. The update client accepted the package delivered over the authenticated connection.

Each system made a locally reasonable decision, but none verified the end-to-end claim that mattered: this exact software package was authorised by Softaculous. Software vendors should sign update metadata and packages, pin trust to publisher-controlled keys and make signature failure terminal. Hosting providers should deploy route-origin validation and prepare more-specific announcements before an incident forces them to improvise.

The practical lesson for defenders is equally blunt. A green certificate and the right hostname are not enough evidence for infrastructure software. When the updater holds root-level authority, package provenance must survive a failure of DNS, routing, hosting and certificate validation.

Sources and further reading

• Virtualizor: Security Incident, BGP Hijacking, published 31 August 2026. The primary page provides no publication time.
• BleepingComputer: Hackers push malicious Virtualizor update in BGP hijacking attack, published 1 September 2026 at 10:45 AM. The page does not state a timezone.