HomeThe LicenseCage BlogVPS & Server SecurityVirtualizor BGP Hijack in 2026: What VPS Operators Should Check Now

Virtualizor BGP Hijack in 2026: What VPS Operators Should Check Now

A recent security incident involving Virtualizor deserves immediate attention from anyone running the VPS control panel on a production node. Between August 28 and August 30, 2026, an unauthorized BGP route announcement diverted traffic for part of Softaculous infrastructure. Virtualizor confirmed that a malicious update package reached a small number of installations during the diversion window.

This is not a reason to assume every Virtualizor server was compromised. It is, however, a reason to treat every Virtualizor operator as potentially in scope for the vendor’s checks until the server has been reviewed.

What happened?

According to Virtualizor’s August 31 advisory, the incident began at about 20:57 UTC on August 28 and normal routing was restored by about 06:10 UTC on August 30. A more-specific BGP announcement diverted traffic destined for a block used by Softaculous services. Because the attacker also obtained a technically valid TLS certificate for affected domains, a diverted connection could look normal to a browser or update client.

The affected infrastructure included the Virtualizor update endpoint. Virtualizor says a malicious update package was delivered to a small number of installations that checked for updates while their traffic was being diverted. The vendor also says it cannot produce a definitive list of affected servers because those malicious responses did not reach its own logs.

Read the official Virtualizor incident advisory for the vendor’s timeline and remediation guidance.

Who is at risk?

The key group is operators of Virtualizor installations that performed update checks during the incident window. The vendor recommends that every Virtualizor operator perform the checks rather than trying to infer exposure from a particular version alone.

That distinction matters for hosting providers: a Virtualizor node is not just another web application. It normally has privileged access to the host that provisions and manages VPS instances. A compromised panel node therefore deserves a more serious response than a compromised low-privilege website.

What to check now

  1. Check for the vendor’s known indicator. Virtualizor identifies /etc/systemd/system/java-jre-update.service as a known indicator of compromise. If it is present, do not simply delete it. Contact Virtualizor support first so evidence can be preserved.
  2. Review system services and scheduled tasks. Look for unfamiliar services, timers, cron entries, startup tasks and other persistence mechanisms created around the incident window.
  3. Review local accounts and SSH keys. Check for accounts, authorized keys or sudo access that your team did not create.
  4. Inspect unexpected outbound connections. A clean-looking web panel does not prove that the host is clean. Review firewall, connection and monitoring logs for unusual destinations or persistent outbound traffic.
  5. Run the vendor’s security scan. Virtualizor published a security scan script as part of its incident response. Use the current copy from the vendor rather than an old cached copy.

Rotate API credentials and restrict access

Even if the file-system checks look clean, rotate Virtualizor API credentials. The vendor specifically recommends resetting API keys, removing keys you do not recognize and restricting API access to trusted source IPs.

The same principle applies to SSH. A VPS control node should not expose administrative interfaces to the entire internet when a narrower management network, VPN or trusted IP allowlist is practical.

If the affected node also holds credentials for billing, provisioning or customer automation, review those credentials separately. A control-panel incident can become a broader infrastructure incident when long-lived API keys are reused across systems.

What about Webuzo and Softaculous?

Virtualizor says it has not identified a malicious package for Webuzo, Softaculous, Backuply or SitePad. That is different from saying those products were impossible to reach during the routing incident. The vendor recommends that operators who performed update checks during the incident window still verify their systems for suspicious activity.

For Softaculous client-area access during the affected period, the vendor also recommends resetting the client-area password, reviewing account activity and regenerating client-center API keys.

What to do after the check

If your Virtualizor host is clean, document the review and keep the panel updated. If you find an indicator of compromise, avoid turning the investigation into a cleanup race. Preserve logs, contact the vendor and decide whether the node should be isolated or rebuilt based on the evidence and the role of the server.

For broader hardening, our VPS security checklist for web hosting servers covers the less glamorous controls that matter just as much: patching, SSH restrictions, backups, monitoring and access management.

FAQ

Does the incident mean every Virtualizor server was hacked?

No. Virtualizor says the malicious package reached a small number of installations. However, the vendor cannot produce a definitive list of affected servers, so every operator should perform the recommended checks.

Should I delete the suspicious systemd service immediately?

No. If the vendor’s known indicator is present, Virtualizor specifically recommends contacting support before simply deleting it so evidence can be preserved.

Should I rotate API keys even if nothing suspicious is found?

Yes. Credential rotation and tighter source-IP restrictions are low-cost defensive steps, and Virtualizor explicitly recommends them as part of the incident response.

Do I need a new Virtualizor license because of this incident?

A license change is not a remediation step by itself. First determine whether the server is affected and follow the vendor’s security guidance. If you need a Virtualizor license for a new or replacement node, you can browse the LicenseCage license catalogue after the infrastructure decision is made.

Bottom line: treat this as a supply-chain and routing incident, not simply an update failure. Check the host, rotate credentials, restrict access and preserve evidence if anything looks wrong.

Image credit: Taylor Vick via Unsplash.


Leave a Reply

Your email address will not be published. Required fields are marked *