Virtualizor warns of BGP hijack that pushed a malicious update

Virtualizor, the VPS control panel from Softaculous, has published a security incident report saying attackers used a BGP hijack to divert its update traffic and deliver a malicious update to a small number of servers.

Two things are true at once. The route diversion was broad, visible across most of the internet's public routing monitors, but the confirmed damage is narrow: a handful of installations that happened to check for updates while the hijack was live.

The hijack ran for about 33.3 hours, from roughly 20:57 UTC on August 28 to 06:10 UTC on August 30, in two waves with an eleven-hour lull in between. During that window, any Virtualizor panel reaching out for an update could have been served a tampered package instead of the real one.

How the traffic was stolen

The attackers announced a more-specific route for 162.55.80.0/24, a slice of Hetzner address space normally covered by the wider 162.55.0.0/16 announcement. Because routers prefer the more-specific route, traffic to update servers in that range followed the fake path, which ran through AS62390 (NexonHost) and transit AS6204 (Zet.net) while keeping Hetzner's AS24940 on the tail so it still looked like the legitimate origin.

To seal the illusion, the attacker obtained a technically valid Let's Encrypt certificate covering Virtualizor and Softaculous domains, so victims saw no certificate warning. This is the routing layer itself being turned into the weapon, a cousin of the router-level intrusions we covered in the Fire Ant campaign against Cisco IOS XR.

Why the fake package went through

The reason a tampered update was accepted is blunt, and the vendor states it plainly: "Our product update clients did not yet cryptographically verify update packages, so a modified package would not have been rejected."

The indicator to look for is a systemd unit at /etc/systemd/system/java-jre-update.service. If it is present, enabled, or running, treat the host as compromised, and do not simply delete it. Virtualizor asks affected operators to contact them, because a malicious response never touched the vendor's own logs, so they cannot produce a complete victim list.

What operators should do now

Virtualizor has shipped version 3.2.9.9 with a mitigation tool, and says cryptographic code signing for update packages is coming. Beyond patching, the advisory tells operators to check for the indicator, rotate and restrict API keys, audit SSH access, users and cron jobs, run the optional scan script hosted on files.virtualizor.com, and reset the client-area password if they logged in during the hijack window.

No malicious package has been confirmed for the sibling products Webuzo, Softaculous, Backuply, or SitePad, but the investigation is open. This is a targeted diversion of a handful of hosts, not a mass worm, and unlike a PaperCut zero-day there is no single CVE to track, only a poisoned update channel.

The takeaway

If you run Virtualizor, do not wait for a victim notification that may never come, because the attack bypassed the logs that would generate one. Update to 3.2.9.9 today, check every host for the java-jre-update.service indicator, and rotate the API keys and panel passwords exposed during the roughly 33-hour window. The wider lesson for anyone shipping software updates is the one the vendor admitted: an update channel without package signing is one hijacked route away from becoming a delivery system for malware.