A BGP hijack diverted Softaculous update traffic to an attacker-controlled server between August 28 and August 30, 2026, delivering a malicious Virtualizor package that established persistent root access on some hypervisors. Virtualizor confirmed the route diversion, and one hosting provider reported that 5 of 34 checked Virtualizor hypervisors were compromised at root level. Because the company has no affected-version range or definitive list of installations that received the tampered package, it is telling every operator to check their servers rather than relying on a version number.

The attack is a clean example of supply-chain compromise through the network layer rather than the code. By announcing an unauthorized BGP route (the first appeared at 20:57:30 UTC on August 28, confirmed via RIPE Stat), the attacker pulled Softaculous traffic to their own server and, during the diversion, obtained a valid Let's Encrypt certificate so connections showed no certificate warning. Any Virtualizor installation that checked for updates during a diverted interval could receive the modified package, with no obvious sign anything was wrong. The incident window ran to 06:10 UTC on August 30.

Why is a BGP hijack update attack so hard to catch?

Because every layer the defender normally trusts behaved normally. BGP has little built-in authentication, so a bogus route can silently reroute traffic, and the attacker's fresh Let's Encrypt certificate meant TLS validated cleanly, removing the one warning a user might have seen. The update mechanism did what it was designed to do, fetch and apply a package, against a server that was, from its point of view, the right one. That is why the durable fix Virtualizor still lists as future work, cryptographic signing of the package itself, matters: signing is what would have made the tampered payload fail even when the transport was subverted.

What should Virtualizor operators do now?

Assume you may be affected and hunt, because there is no safe-version shortcut. Virtualizor advises running the official scanner, rotating and restricting API credentials, and auditing each server for persistence and unauthorized access, and where indicators are found the safe path is to rebuild rather than clean in place. Anyone who ran an update during the roughly 33-hour diversion window should treat that host as suspect regardless of how normal the update appeared.

Our read

This incident is a reminder that a signed transport is not a signed artifact: TLS proves you reached some server, not that the package is authentic. The missing control is end-to-end package signing, and until it exists, update integrity depends on routing that BGP cannot guarantee. For anyone operating infrastructure that auto-updates, the lesson is to verify the integrity of what you install, not just the security of the connection, and to treat any update taken during a known diversion window as untrusted. Continuous verification of your own hosts, hunting for the persistence this kind of compromise leaves, is the difference between finding it and hosting it.

Reporting by The Hacker News; incident timeline confirmed via RIPE Stat and Virtualizor's advisory. Sources linked above.

Related: What is a software supply chain attack? and Code security for SMBs.