The Attack That Came Through the Routing Table

For 33 hours between August 28 and September 1, an unknown attacker controlled which servers got which updates from Softaculous, the company behind Virtualizor hypervisor management software. Not through a compromised code repository, not through stolen credentials, not through a vulnerability in the application itself.

Through the routing table.

The attack began at 20:57 UTC on August 28 when someone started announcing a more specific block of IP addresses that belonged to Hetzner, one of Softaculous's upstream providers. Border Gateway Protocol (BGP) — the system that directs traffic across the internet — works on longest-prefix matching: announce a more specific route than the legitimate one, and traffic flows to you instead. It is a design decision baked into internet infrastructure, and it has been weaponized for decades. What changed here is how far the attacker took it.

They secured a valid TLS certificate from Let's Encrypt by routing the domain validation challenge through the hijacked network. Let's Encrypt verified the domain, issued the certificate, and handed an attacker the cryptographic proof that the malicious server was legitimate. Then they pushed a backdoored Virtualizor update — fake version 3.2.9.8 — that installed persistent root-level access on hypervisors.

The update client accepted it without question, because it did not cryptographically verify the package. Valid TLS certificate plus no signature verification equals supply-chain compromise delivered at internet scale.

What happened

Virtualizor is widely deployed hypervisor management software used by hosting providers. When a provider runs Virtualizor, that software controls the physical servers (hypervisors) that host all their customers' virtual machines. Root access to a hypervisor means root access to every VM it runs. The attacker knew this.

During the 33-hour hijack window, an estimated 72% of Virtualizor installations had their update traffic routed through attacker-controlled infrastructure at some point. Not all of them received the malicious update — timing and update schedules mattered — but the exposure was broad and the window was long.

One hosting provider checked 34 of their Virtualizor hypervisors after the disclosure. Five were compromised. Five hypervisors, each running dozens or hundreds of guest VMs, each now under attacker control. Multiply that across every affected provider and the scale becomes clear: this was not targeted exploitation of a few high-value systems. This was supply-chain access delivered to whoever happened to update during the window.

Softaculous released version 3.2.9.9 on September 1 with what they are calling a "Security Analyzer" tool in the admin panel, which tells you everything you need to know about how confident they are that the malicious version is gone. If you have to ship a post-incident forensics tool in the product itself, you do not know who is still running the backdoored build.

The point of failure

• BGP hijacking is not new.* It has been documented, studied, exploited, and presented at conferences for as long as BGP has existed. The routing layer operates on trust: if you announce a route, the protocol believes you. Cryptographic route validation exists (RPKI, ROAs), but adoption is inconsistent and enforcement is opt-in. Hetzner's routes were hijacked because someone announced them, and enough of the internet accepted the announcement.
• Let's Encrypt issuing a valid certificate to attacker-controlled infrastructure is not a failure of Let's Encrypt.* The certificate authority did exactly what it is designed to do: it validated that the entity requesting a certificate controlled the domain at the time of the validation challenge. The attacker controlled the domain's network path for 33 hours, routed the validation traffic through their infrastructure, and passed. The certificate was legitimately issued to an illegitimate party, which is the nightmare scenario domain validation was never designed to prevent.
• Virtualizor's update client not cryptographically verifying packages is the failure that turned infrastructure access into persistent compromise.* A valid TLS certificate proves the server you are talking to is the server the DNS name resolves to. It does not prove the content the server is delivering is authentic. For that, you need the package itself to carry a cryptographic signature from the publisher, verified against a public key the client already trusts.

Virtualizor had TLS but no package signing. The attacker had a valid certificate and a 33-hour window. That was enough.

Why this matters

Hosting providers run infrastructure that supports thousands of downstream customers. When a hypervisor is compromised, every VM it hosts is accessible to the attacker: customer data, application secrets, database credentials, source code, everything a business considers too sensitive to put anywhere else. That access persists until someone notices, investigates, and rebuilds from a known-good image — and if the compromised hypervisor was itself the build source, there may not be a known-good image left.

Supply-chain attacks work because they target the thing everyone trusts. Developers trust their package managers. Enterprises trust their software vendors. Hosting providers trust their upstream update channels. This attack went after the routing layer underneath all of those, and it worked because the update client had no way to distinguish a legitimate build from a hijacked one beyond "the TLS certificate is valid."

A TLS certificate is proof of who you are talking to right now. It is not proof of who you should be talking to, and it is not proof that what they are handing you is safe. That verification — the cryptographic signature on the package itself — was missing.

The 72% problem

During the active hijack, an estimated 72% of Virtualizor update requests were routed through attacker-controlled infrastructure at some point. Not all of those servers got the malicious update, but all of them could have. The update client had no way to know.

That percentage is the infrastructure problem in a single number. BGP is designed to dynamically route around failures and optimize paths, which means traffic shifts constantly based on which routes are being announced. For 33 hours, the attacker's route was more specific than the legitimate one, and a significant fraction of the internet honored it.

Enterprises spend millions on endpoint detection, application security, and perimeter defenses. None of it matters when the routing layer delivers your updates to someone else's server and your update client accepts what it gets handed. This is not a vulnerability in the traditional sense. This is a design assumption — "the network delivers packets to the right place" — that an attacker turned into an attack vector.

What should have happened

• RPKI/ROA deployment.* Resource Public Key Infrastructure and Route Origin Authorizations allow network operators to cryptographically sign their route announcements, and allow recipients to reject unsigned or invalid routes. Hetzner's routes could have been protected this way. Adoption is growing, but it is not universal, and many networks still accept unsigned routes by default.
• Package signing, enforced.* Every software update should carry a cryptographic signature from the publisher, verified by the client before installation. The signature should be checked against a public key the client ships with or retrieves over a separate, independently validated channel — not from the same server delivering the update. Virtualizor's update client should have refused to install an unsigned package, and it should have refused to install a package signed with a key it did not recognize.
• Defense in depth.* TLS is necessary. It is not sufficient. A valid certificate proves the connection is encrypted and the server matches the DNS name. It does not prove the server is legitimate, and it does not prove the content is authentic. Those are separate questions that require separate answers. Virtualizor relied on TLS alone, and when the attacker got a valid certificate, there was no second layer of defense.

The update nobody saw coming

Softaculous's September 1 disclosure reported that routing had been restored, the fraudulent certificate was reported for revocation, and version 3.2.9.9 shipped with a post-incident forensic tool. What it did not say was how many customers were affected, how many hypervisors remain compromised, or whether any of the compromised systems were used to pivot into customer environments.

Hosting providers who run Virtualizor are now in the position of investigating whether their infrastructure — the thing their entire business is built on — is under attacker control, using a tool the vendor shipped after the fact. That is not incident response. That is archaeology.

For 33 hours, the routing layer was the attack vector, a valid TLS certificate was the credential, and the absence of package signing was the control that failed. The internet routed traffic where it was told to go, Let's Encrypt issued a certificate to the entity that controlled the domain at validation time, and the update client installed what it was given.

All of it worked as designed. None of it was safe.