Virtualizor Hit by BGP Hijacking Attack That Delivered Malicious Software Updates

A recent security incident involving Virtualizor has exposed how weaknesses in internet routing can become a supply-chain security problem.

Virtualizor disclosed that between approximately 20:57 UTC on August 28, 2026, and 06:10 UTC on August 30, 2026, attackers hijacked a portion of the IP address space used by Softaculous services and redirected traffic to an attacker-controlled server.

The incident affected the infrastructure used by Virtualizor and other Softaculous services. Most significantly, the diverted traffic included the Virtualizor software update endpoint.

Virtualizor confirmed that a malicious update package was delivered to a small number of installations that checked for updates while their traffic was being redirected. The company said it cannot produce a definitive list of affected servers and is therefore asking all Virtualizor operators to perform security checks.

What happened in the Virtualizor BGP hijacking incident?

The incident centred on the IP prefix 162.55.80.0/24, which is part of infrastructure hosted at Hetzner.

At approximately 20:57 UTC on August 28, the network identified as AS62390 (NexonHost) began announcing the /24 prefix without authorisation through AS6204 (Zet.net).

The announcement was more specific than Hetzner's normal /16 announcement covering the surrounding address space. Under standard BGP route selection, the more-specific route could take precedence, causing traffic destined for the affected addresses to be redirected.

This created an opportunity for the attacker to intercept traffic intended for Softaculous infrastructure.

A valid TLS certificate made the interception harder to detect

The attack was particularly significant because the attacker was able to obtain a technically valid TLS certificate for affected domains.

Virtualizor said the certificate was issued through Let's Encrypt after domain-ownership validation traffic was itself redirected through the hijacked route.

As a result, affected connections did not generate the normal browser or client certificate warning that users might expect when connecting to an impostor server. The certificate covered domains including virtualizor.com, api.virtualizor.com and files.virtualizor.com, among others.

This is an important aspect of the incident because HTTPS alone did not protect users once the routing path and certificate validation process had both been compromised.

The hijack occurred in two major waves

Virtualizor reconstructed the incident using public routing information from RIPE.

The first major wave began around 21:00 UTC on August 28 and continued until approximately 08:50 UTC on August 29.

After Virtualizor reported the issue to Hetzner, Hetzner began directly announcing the affected /24 around 08:50 UTC. Diversion subsequently dropped to essentially zero.

A second wave began around 20:00 UTC on August 29 and continued until approximately 06:00 UTC on August 30. The unauthorised route was withdrawn around 06:10 UTC, after which Virtualizor reported no further diversion in the observed routing data.

Virtualizor's measurements indicate that all 368 RIPE RIS collector peers carried the hijacked route at some point during the incident.

During active periods, the route reached roughly 72% of the full 368-peer sample, although Virtualizor explicitly notes that this is a routing-topology measurement and not a measurement of traffic volume. The route also experienced substantial instability, with approximately 10,600 route withdrawals recorded during the incident window.

Malicious Virtualizor update delivered to affected servers

The most serious consequence was the interception of the Virtualizor software update mechanism.

Virtualizor confirmed that installations whose traffic was diverted during an update check could receive a malicious package from the attacker-controlled infrastructure.

The company also disclosed that its update clients did not yet cryptographically verify update packages. This meant that a modified package would not have been rejected by package-signing verification.

Virtualizor believes only a small number of installations actually received the malicious package, but the company cannot identify every affected server because responses served by the attacker did not reach Virtualizor's own logs.

This creates an important distinction between the potential exposure window and the confirmed number of compromised systems.

The company has confirmed delivery to a small number of installations, but it has not provided a definitive total.

Known indicator of compromise

Virtualizor has identified a specific indicator that administrators should investigate:

/etc/systemd/system/java-jre-update.service

The company says that the presence of this systemd unit, together with an enabled or running java-jre-update service, indicates that the server was affected.

Virtualizor advises administrators not to simply delete the indicator. Instead, operators should contact the company so evidence can be preserved and the incident can be investigated appropriately.

What Virtualizor users should do

Virtualizor recommends that operators treat every Virtualizor installation as potentially in scope because the company cannot provide a definitive list of affected systems.

Administrators should:

1. Check for /etc/systemd/system/java-jre-update.service.

2. Rotate Virtualizor API credentials.

3. Restrict API access to trusted IP addresses.

4. Remove unfamiliar API keys.

5. Review SSH keys and user accounts.

6. Check scheduled tasks and cron jobs for unexpected entries.

7. Investigate unusual outbound connections.

8. Restrict SSH access to trusted IP addresses.

9. Contact Virtualizor support before remediation if signs of compromise are found.

10. Use the security scanning tool provided by Virtualizor as part of the investigation.

The company also recommends regenerating Softaculous Client Center API keys and updating them on affected servers.

What about Webuzo, Softaculous, Backuply and SitePad?

Virtualizor said it has not identified a malicious package for Webuzo, Softaculous, Backuply or SitePad.

However, as a precaution, the company recommends that operators of these products verify systems that performed an update check during the incident window and investigate anything suspicious.

Additional details were not disclosed in the announcement.

Client-area and account exposure

The incident was not limited to software updates.

The affected infrastructure also served the Softaculous client area and billing site. Virtualizor said that users who logged into softaculous.com/clients or entered payment information during the incident window may have had their sessions diverted to the attacker-controlled server.

Users who accessed the client area during the affected period should reset their passwords.

If the same password was reused on other services, it should also be changed there.

Virtualizor additionally recommends reviewing account activity and checking payment-card statements if card information was entered during the affected period.

The company said it is invalidating client-area sessions from the affected period and recommends regenerating Client Center API keys.

Virtualizor's response

Virtualizor said it has launched Virtualizor 3.2.9.9, which includes a mitigation tool for known exploits.

The company also reported the fraudulent certificate to Let's Encrypt for revocation and notified relevant network operators and CERTs.

It reconstructed the incident using public routing data and said it plans to implement a code-signing mechanism for all packages. Virtualizor also said it intends to migrate to improved infrastructure.

Why this incident matters

Editorial analysis: The incident highlights a broader industry shift toward treating software update infrastructure as a high-value security boundary.

Software updates are normally trusted because they originate from a vendor's infrastructure and are delivered over encrypted connections. This incident demonstrates that those controls can become less effective when attackers can manipulate the network path and obtain a valid certificate for the affected domain.

For enterprises and hosting providers, the case reinforces the importance of using multiple independent trust mechanisms rather than relying solely on HTTPS.

Cryptographic package signing is one such mechanism. If software packages are independently verified before installation, intercepting network traffic becomes less useful because the attacker would still need to produce a package with a valid vendor signature.

The incident also demonstrates why network-level monitoring matters. BGP anomalies can affect services without changing the application itself.

Virtualizor's use of RIPE routing data to reconstruct the attack provides an example of how external routing visibility can help organisations understand an incident when conventional application logs are incomplete.

The larger security lesson

The Virtualizor incident sits at the intersection of BGP security, software supply-chain security and infrastructure security.

The attack did not begin with a conventional vulnerability in a web application. Instead, it manipulated the route used to reach trusted infrastructure.

Once traffic was redirected, the attacker was positioned to impersonate the affected services. The ability to obtain a technically valid TLS certificate made the interception harder to identify through ordinary certificate warnings.

The malicious update delivery then turned a network-routing incident into a software supply-chain security event.

For infrastructure operators, the key lesson is that trust should be layered.

Network routing controls, TLS, package signing, access restrictions, credential rotation, endpoint monitoring and incident-response procedures each address different parts of the attack chain.

No single control should be expected to provide complete protection.

Current status

Virtualizor says routing has been fully restored and that it observed no further diversion after approximately 06:10 UTC on August 30.

The investigation remains relevant for administrators because Virtualizor cannot provide a definitive list of affected installations.

Operators should therefore treat the incident as an infrastructure security investigation rather than assuming that normal routing restoration means every server is clean.