Was Virtualizor Hacked? What the 2026 BGP Hijack Means for VPS Operators

Security advisory · Updated 1 September 2026

Virtualizor has reported a security incident in which a BGP hijack diverted traffic intended for parts of its infrastructure. According to the vendor, the attacker obtained a technically valid TLS certificate and delivered a malicious Virtualizor update package to a small number of installations.

The short answer to “Was Virtualizor hacked?” requires some precision. The published account does not describe a conventional vulnerability in the Virtualizor application. It describes a routing and software-supply-chain incident: traffic to a trusted update service was redirected, the redirected service appeared legitimate over HTTPS, and affected Virtualizor clients did not cryptographically verify the downloaded package before installation.

Virtualizor cannot produce a definitive list of affected installations because diverted requests went to infrastructure outside its own logs. Its advice is therefore that every Virtualizor operator should perform the published checks.

What happened in the Virtualizor security incident?

Virtualizor states that the incident began at approximately 20:57 UTC on 28 August 2026 and ended at approximately 06:10 UTC on 30 August 2026. The affected address range was 162.55.80.0/24, part of Hetzner infrastructure used by Softaculous services including Virtualizor’s software update endpoint and client area.

The vendor reports that an unauthorised, more-specific announcement for this /24 travelled through the internet routing system. Internet routers generally prefer the most specific matching route, so networks accepting that announcement sent traffic toward the unauthorised destination instead of the legitimate service.

Virtualizor’s analysis identifies AS62390 on the diverted path via AS6204 while retaining AS24940, Hetzner, as the apparent origin. This detail matters: the event was not simply an unrelated network claiming to be the origin. The legitimate origin remained at the end of the visible AS path while the path itself was manipulated.

The unauthorised route appeared in two sustained waves. During active periods, Virtualizor reports that it was visible to a large proportion of the RIPE Routing Information Service collector set. A server would only have received the malicious package if its update request completed while its network was following the diverted route.

Primary source: Virtualizor’s official BGP hijacking incident report.

Incident timeline in Singapore time

Singapore time (SGT)	Reported event
29 Aug, approximately 4:57am	Unauthorised route announcement begins
29 Aug, approximately 4:57am–4:50pm	First sustained diversion wave
29 Aug, approximately 4:00pm–4:50pm	Active interception independently confirmed by Virtualizor
29 Aug, approximately 4:50pm	Hetzner announces the affected /24 directly and diversion drops rapidly
29 Aug, approximately 5:00pm–30 Aug, 4:00am	Approximately 11-hour lull
30 Aug, approximately 4:00am–2:00pm	Second sustained diversion wave
30 Aug, approximately 2:10pm	Unauthorised route withdrawn and normal routing restored

These times are conversions of the approximate UTC timeline in Virtualizor’s report. They should be treated as an incident-response window rather than proof that any particular server was affected.

Was every Virtualizor server compromised?

No. Virtualizor says the malicious update reached a small number of installations rather than the general user base.

However, the company cannot identify every affected installation from its own logs. Requests served by an attacker during a routing diversion do not reach the legitimate update service. The absence of a request in the vendor’s logs therefore cannot prove that a server was safe.

Virtualizor advises all operators to check their servers, particularly if an update could have been requested during the incident window.

How a BGP hijack became a software-supply-chain compromise

1. Internet routing sent traffic to the wrong system

BGP tells networks how to reach IP address ranges. It was designed around cooperation between networks, and route selection can accept an incorrect or manipulated announcement unless operators apply effective filtering and validation. The unauthorised /24 was more specific than Hetzner’s surrounding /16, so it was preferred by networks that accepted it.

2. The diverted service presented a valid TLS certificate

Virtualizor reports that the attacker obtained a valid Let’s Encrypt certificate covering Virtualizor and other Softaculous-related domains. Certificate-authority domain validation was reportedly routed through the same hijack, allowing the attacker-controlled service to answer the validation request. Affected connections could therefore display normal HTTPS without a certificate warning.

Let’s Encrypt introduced multi-perspective domain validation to reduce the risk that a localised routing attack can fool a certificate authority. Current CA/Browser Forum requirements also require certificate authorities to corroborate certain validation methods from multiple network perspectives. These safeguards make attacks harder, but they are not equivalent to cryptographic proof of the software package.

The incident report does not provide enough certificate-authority telemetry to establish precisely why the required perspectives corroborated the request. The safe conclusion is narrower: a trusted certificate was reportedly obtained during a broadly propagated routing incident, so HTTPS alone did not establish that the downloaded executable package was authentic.

3. The update client did not cryptographically verify the package

Virtualizor states that its update clients did not yet cryptographically verify update packages. Once traffic had been diverted to a server with a valid certificate, the client did not have an independent, pinned trust mechanism to reject a package that was not signed by the software publisher.

This is the decisive supply-chain lesson. Transport encryption protects a connection, but a privileged update client should also verify the authenticity and integrity of the package it is about to execute. NIST describes code signing as providing integrity and source authentication. The Update Framework extends this model with signed, versioned and expiring metadata, separated roles and threshold trust.

Why RPKI alone may not have stopped this exact event

Resource Public Key Infrastructure and Route Origin Authorisations help networks validate that an autonomous system is authorised to originate a prefix. They are important routing-security controls.

However, Virtualizor’s reconstruction says the unauthorised announcement retained Hetzner’s AS24940 as the apparent origin. RFC 7115 explicitly notes that origin validation does not validate the entire AS_PATH; paths can still be manipulated maliciously or accidentally.

A route can therefore potentially appear origin-valid while still containing an unauthorised path. RPKI remains valuable, but it should be combined with provider filtering, route monitoring, accurate routing-registry data, incident contacts and stronger path-validation controls where available.

What Virtualizor administrators should check now

Important: This is a summary of the vendor’s published guidance, not a replacement for its live incident instructions. Check the official report for changes before taking action.

Check the published indicator of compromise

Virtualizor identifies the following systemd service file as a known indicator:

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

If the file or corresponding java-jre-update service is present, Virtualizor says the server was affected. Do not simply delete it. Isolate the system as appropriate, preserve evidence and contact the vendor or a qualified incident-response team before remediation. Deleting one indicator does not remove other persistence or establish that the host is trustworthy.

Rotate and restrict Virtualizor API credentials

Reset API credentials in the Virtualizor master administration panel, remove unknown keys and restrict API access to trusted source addresses wherever operationally possible. Credentials accessible to a compromised privileged service should be treated as exposed even when there is no evidence they were used.

Audit privileged access and persistence

Review at least:

• root and administrator SSH keys;
• unexpected local accounts or privilege changes;
• cron jobs, timers and scheduled tasks;
• new or modified systemd services;
• unexpected outbound connections;
• authentication, API and administration logs; and
• changes to virtualization-management files and web interfaces.

Restrict SSH and administrative interfaces to trusted networks or IP addresses wherever practical.

Treat confirmed execution as a full host compromise

A virtualization management node is a high-trust system. If an unauthorised update executed with privileged access, the investigation should consider the hypervisor, management plane, credentials and hosted workloads—not only the visible indicator.

For a confirmed compromise, a clean rebuild from trusted installation sources may provide greater assurance than attempting to remove individual files. Preserve forensic evidence before rebuilding and coordinate the decision with the vendor, customers and incident-response specialists.

Were Softaculous, Webuzo and other products affected?

At this article’s research cut-off, Virtualizor stated that it had not identified a malicious package for its other products, including Webuzo and Softaculous, while noting that the investigation was continuing.

That is not the same as proving every related service was unaffected. Operators should follow the vendor’s current guidance, check whether their systems contacted affected infrastructure and review unexpected activity.

How QUAPE’s KVM and XCP-ng platform differs

QUAPE’s VPS platform does not use Virtualizor as its virtualization control plane and was not within the scope of the malicious-update mechanism described by Virtualizor.

QUAPE operates its own virtualization control plane across KVM and XCP-ng hypervisors. KVM is the virtualization interface built into the Linux kernel, while XCP-ng is a separate Xen-based virtualization platform. QUAPE’s orchestration and management layer controls how virtual machines are provisioned and operated across these environments.

Because QUAPE does not depend on the Virtualizor control plane or update endpoint, our hypervisors did not request or execute the Virtualizor package involved in this incident. This removes the specific third-party update-channel dependency described in the vendor’s report.

Custom infrastructure is not automatically secure merely because it is custom. It changes ownership of the risk. An operator using an in-house platform must maintain its own secure development lifecycle, privileged-access controls, release process, monitoring, backup strategy and incident-response capability.

For QUAPE, the architectural advantage is direct control: we decide which components enter the virtualization stack, test changes against our environment and respond without relying on a third-party virtualization panel to control the underlying release path.

Security controls every virtualization platform should apply

Secure release and update controls

• Cryptographically sign privileged packages and metadata.
• Verify signatures client-side before installation.
• Separate build, signing and distribution responsibilities.
• Protect high-value signing keys offline or with suitable hardware-backed controls.
• Reject expired, rolled-back or unexpectedly versioned update metadata.
• Stage infrastructure changes before broad deployment.
• Maintain a tested process for revoking keys and stopping updates.

Management-plane controls

• Keep hypervisor and orchestration interfaces off the public internet wherever possible.
• Apply least privilege and multi-factor authentication.
• Restrict APIs and SSH by network location when operationally feasible.
• Use short-lived or regularly rotated credentials.
• Record privileged actions in protected, centralised logs.
• Monitor for new services, keys, accounts and scheduled tasks.

Routing, certificate and recovery controls

• Maintain accurate RPKI ROAs and routing-registry information.
• Monitor route announcements affecting important prefixes.
• Confirm upstream providers apply appropriate route filtering.
• Publish CAA records and monitor Certificate Transparency logs.
• Keep backups separated from the administrative trust domain.
• Test restoration of management nodes and customer workloads.
• Define when a host must be rebuilt rather than cleaned.

Questions to ask a Singapore VPS hosting provider

1. Which virtualization and control-plane software manages the service?
2. Can a third-party vendor remotely push privileged updates?
3. Are update packages cryptographically signed and verified?
4. How are management interfaces, SSH and APIs restricted?
5. How does the provider monitor unexpected BGP route and TLS certificate changes?
6. Are workloads backed up outside the primary management environment?
7. Can the platform be restored without depending on an affected control plane?
8. Who responds locally if an international vendor or upstream provider has an incident?

These questions are more useful than asking whether any platform is “unhackable.” No responsible provider can make that promise. The practical objective is to reduce unnecessary dependencies, limit the blast radius and recover predictably when a control fails.

Frequently asked questions

Primary technical sources

1. Virtualizor: Security Incident – BGP Hijacking
2. RIPE NCC: BGP Origin Validation
3. RFC 7115: RPKI-Based Origin Validation Operation
4. Let’s Encrypt: Multi-Perspective Validation
5. CA/Browser Forum: TLS Baseline Requirements
6. NIST: Security Considerations for Code Signing
7. The Update Framework: Overview
8. Linux kernel documentation: KVM