# When Your Update Server Becomes the Attack: The BGP Hijack That Rooted Hosting Hypervisors
Five compromised hypervisors out of 34 checked. Root access. And the attack vector was the software update mechanism itself — poisoned at the routing layer before the payload even touched disk.
That's the story of a BGP hijacking campaign that targeted Virtualizor, a widely-deployed server virtualization management panel, sometime around August 28. Attackers didn't breach Virtualizor's infrastructure directly. They didn't need to. Instead, they hijacked the Border Gateway Protocol routes used by Softaculous — the auto-installer platform that handles Virtualizor's update traffic — and redirected it to their own infrastructure. Hosting providers who checked for updates during that window received a malicious package instead of a legitimate one. Some of them got root backdoors in exchange.
## How BGP Becomes a Supply Chain Weapon
BGP is the internet's routing protocol — the system that tells traffic which network paths to take to reach its destination. It was designed in an era when internet operators trusted each other, and that trust model has never been fully fixed. Attackers with access to a BGP-speaking network can announce false routes, claiming to own IP space they don't. Traffic meant for a legitimate destination gets pulled toward the attacker's infrastructure instead.
This has happened before in other contexts: cryptomining operations that hijacked routes to Amazon's Route 53 DNS service in 2018 to steal cryptocurrency, state-sponsored actors using BGP manipulation for mass surveillance, financial services firms watching their traffic mysteriously appear on Russian networks. The attack surface is well-documented. The defenses — Resource Public Key Infrastructure (RPKI), BGP route filtering, prefix validation — exist but are inconsistently deployed across the internet.
What makes this incident different isn't the BGP hijack itself. It's what the attackers did with the diverted traffic. Rather than intercepting data in transit or redirecting users to phishing pages, they targeted the software update pipeline. They stood up a malicious mirror, served a weaponized Virtualizor package to systems that trusted the update server, and walked away with persistent root access on the machines that installed it.
That's a supply chain attack at the network layer. And it's a technique that scales.
## Hypervisors Are Not Like Other Systems
The 5-of-34 figure that one affected hosting provider reported might sound modest — roughly 15% of their checked installations. It isn't modest at all.
Hypervisors are the substrate everything else runs on. A root-level compromise on a hypervisor isn't like owning a single web server. It's owning every virtual machine that runs on it: every customer website, every database, every application, every credential in memory. In a shared hosting environment, a single compromised hypervisor can expose hundreds or thousands of customer workloads simultaneously.
Virtualizor specifically manages KVM and OpenVZ virtualization for web hosting providers. Its users tend to be small-to-midsize hosting operations — exactly the kind of infrastructure that runs on thin margins, deferred patching, and limited security staffing. They're also the kind of providers that their own customers trust implicitly, often without knowing it.
The persistent root access component compounds this. These aren't opportunistic intrusions where the attacker grabbed credentials and left. Persistent access means the backdoor survived reboots, survived legitimate updates, survived the incident window itself. How long that window was — and how many providers were affected beyond the one that published its numbers — hasn't been fully established.
## What the Forensics Should Be Chasing
The immediate question for any affected provider is whether the compromise is still active. A package that installs a backdoor at root on a hypervisor has options: it can plant SSH keys, install a rootkit, establish a reverse shell, add a cron job, modify system binaries. Without knowing the specific malicious payload, defenders need to assume the worst.
Incident responders working these systems should be looking at:
Reinstalling the hypervisor OS is likely unavoidable in confirmed-compromise cases. For hosting providers, that means coordinating customer migrations under incident conditions — painful, expensive, and time-sensitive.
## HackWire Analysis
The security community has spent years warning that BGP's trust model creates systemic risk, but the conversation has mostly focused on traffic interception and availability attacks. This incident suggests attackers have internalized something more sophisticated: the update channel is a privileged trust relationship, and if you can hijack the route to the update server, you can abuse that trust at scale without ever touching the vendor's actual infrastructure.
This is conceptually adjacent to what happened with SolarWinds — not technically identical, but strategically similar. In both cases, the attack vector wasn't a vulnerability in the target software. It was an abuse of the distribution mechanism that customers trusted. SolarWinds required nation-state access to build infrastructure. BGP hijacking requires network access and some sophistication, but it's a technique with documented playbooks and known threat actors.
What other coverage is largely missing: the hosting provider ecosystem is uniquely vulnerable to exactly this attack pattern. Small hosting companies auto-update control panel software because they can't maintain a dedicated security team to manually vet every patch. That automatic trust is exactly what this attack exploited. Any provider running Virtualizor should be treating August 28 as a hard line — check your hypervisors against that date, verify your package checksums, and assume compromise until forensics say otherwise.
The broader implication: software vendors who distribute updates over infrastructure they don't fully control — which is most of them — need to think about RPKI deployment, update signing with verified keys, and out-of-band integrity verification mechanisms. Update packages should be signed so that a poisoned mirror can't substitute a malicious payload regardless of where the traffic was routed. Whether Virtualizor had signing in place and why it didn't prevent this is a question that deserves a direct answer.
The number of affected providers beyond the one that went public is almost certainly higher. Most hosting companies won't audit 34 hypervisors and publish the results. They'll quietly patch and move on.
— HackWire Editorial
## Related Coverage