Between Friday 28 August at 20:57 UTC and Sunday 30 August at 06:10, a network that had no business doing so began announcing 162.55.80.0/24 to the rest of the internet, a slice of Hetzner's address space that houses Softaculous' update and billing servers. For as long as the announcement held, traffic from most of the internet bound for those addresses landed on a server run by the attacker.
From that position the attacker obtained a valid TLS certificate for 26 of the company's domains and served a backdoored update for Virtualizor, the control panel many hosting providers use to run their virtual servers. One provider has reported that 5 of its 34 hypervisors had the backdoor installed and running as root.
The vendor reconstructed the incident from public routing data, and BGPKIT verified it independently against the raw BGP messages recorded by RIPE and Route Views collectors. At Hard2bit we will be using it as a case study, because it chains three unrelated mechanisms all the way to a compromised hypervisor.
How do you trojanise an update without touching the vendor's server?
The chain has three links, and none of them involved a software vulnerability in the usual sense.
First link: a more specific route with the legitimate origin
BGP, the protocol through which internet networks tell each other which addresses they reach, always prefers the more specific route. Hetzner announces 162.55.0.0/16; autonomous system AS62390, registered as NexonHost, began announcing the sub-block 162.55.80.0/24 through transit provider AS6204 (ZET.NET), and every network that accepted the announcement stopped sending traffic to Hetzner. According to Virtualizor's advisory, at the peaks roughly 72% of RIPE RIS's 368 vantage points were carrying the forged route as best path, and all 368 saw it at some point.
What sets this apart from a crude hijack is that the announcement kept Hetzner (AS24940) as the apparent origin at the end of the path, with AS62390 inserted just before it.
There were two waves, of around 12 and 10 hours, with an 11-hour lull between them; the route flapped so badly that BGPKIT counts some 10,600 withdrawals in 33 hours. The first wave ended when Hetzner announced the /24 itself, about 12 hours in and, by Softaculous' account, after several reports from the victim. Hetzner withdrew that announcement at around 14:30 UTC on the 29th, and the second wave began five hours later with the same reach.
Second link: a valid certificate issued to whoever held the route
With traffic diverted, the impostor asked Let's Encrypt for a certificate covering Softaculous' domains. Automated domain-control validation is an HTTP request to the domain's address, and that request travelled down the hijacked route too. The outcome was a valid certificate for 26 names, virtualizor.com, api.virtualizor.com and files.virtualizor.com among them, and according to the vendor the diverted connections showed no certificate warning.
Certificate authorities validate from several network vantage points precisely to withstand route hijacks, a practice the CA/Browser Forum has been phasing in as a requirement since March 2025. That defence assumes the hijack is regional. When the forged route reaches three in four vantage points worldwide, the CA's validation points most likely all see the same thing. BGPKIT notes something else: the certificate stayed valid after routing was restored, until it was revoked (the advisory gives no time), and according to BGPKIT the second wave used it again.
Third link: an update client that trusted the channel
The last control was Virtualizor itself. Its update client, the vendor acknowledges, did not cryptographically verify packages, so a valid HTTPS response from a server bearing the right name was enough. The fake update presented itself as version 3.2.9.8; affected servers logged a successful update and stayed on 3.2.9.7, a mismatch that BGPKIT, drawing on operator reports, flags as an indicator of compromise in its own right.
According to the compromised provider's analysis as reported by The Hacker News, the package altered three legitimate Virtualizor files and a root cron job later executed the inserted code: it added an attacker SSH key to the root account, installed Java if it was missing, fetched a Java payload and left it running as a systemd service so it survived reboots, that is, with persistence, and created an extra account named proxyuser. Root on a hypervisor is root on every virtual machine it hosts.
What is known about the impact
Virtualizor says only a small number of installations received the malicious package but cannot produce a list: the forged responses were served by the attacker and never touched its logs. It therefore asks every operator to check every server. One hosting provider (AlbaHost, on the LowEndTalk forum) has reported that 5 of the 34 hypervisors it examined carried the modifications, with no evidence so far of tampering with customers' virtual machines.
The client area and payment pages sat behind the hijacked addresses as well; as of 2 September there is no confirmed theft of accounts or payment data, and the vendor has identified no malicious package for its other products.
On 1 September Virtualizor shipped patch 9 of release 3.2.9 with a security analyser and a check script. Cryptographic package signing appears on its list of measures as work still to come, as SecurityWeek also notes, and the same list includes a move to new infrastructure.
Why didn't RPKI stop it?
The reflex response to a BGP hijack is to ask about RPKI, the system that lets address holders publish which autonomous system may originate their prefixes. The answer is a surprise, because the forged route was valid under RPKI. Hetzner's authorisation (ROA) covers 162.55.0.0/16 with origin AS24940 and a maximum length of 24 bits; because the forged announcement kept AS24940 as origin and was precisely a /24, any router performing origin validation accepted it. Doug Madory of Kentik summed it up on Bluesky, as Risky Business reports: the hijackers forged the origin to make the route validate.
From there BGPKIT draws three conclusions. Had the ROA been signed for the /16 alone, without a maximum length of 24, as RFC 9319 recommends, the /24 would have been invalid and validating networks would have dropped it. The question RPKI cannot answer is which AS may sit immediately before the origin on the path, and that gap is what ASPA, a draft extension no network on this path had published, is designed to close. And the oldest control of all would have confined the announcement to a single hop, a customer prefix filter at the transit provider that let it through.
For anyone buying hosting, that comes down to four questions for the provider: whether its ROAs avoid the maximum-length field, whether it publishes ASPA, whether its transits filter customer prefixes and whether it watches for more-specific announcements inside its own blocks. In the supplier assessment questionnaires we tend to see, those questions almost never appear; this case makes the argument for adding them.
What to do if you run Virtualizor
Virtualizor asks operators to treat every server as affected until proven otherwise, and the provider that has spoken publicly maintains that, once root compromise is confirmed, a clean rebuild is the only reliable remediation. The steps, drawing on Virtualizor's guidance:
- Check for the systemd unit java-jre-update.service and run the official check script, which searches for that and the rest of the known indicators; if it finds anything, preserve the evidence and contact support before cleaning.
- Compare the installed version with what the update logs claim.
- Regenerate every API credential in the panel, restrict API access to trusted addresses and remove any credential you do not recognise.
- Audit unknown SSH keys on root, new accounts, scheduled tasks and unexpected outbound connections, and restrict SSH to trusted addresses.
- Change the Softaculous client-area password if you logged in during the window, and regenerate client-centre API credentials.
Virtualizor's analyser looks for the known indicators; trust in the system has to be rebuilt separately. If evidence turns up, the case becomes a supply chain attack with potential impact on the customers behind every virtual machine, and NIS2 notification deadlines apply to anyone within its scope. The incident response team at Hard2bit comes in, bounding the scope when the supplier cannot tell you whether you are on the list.
What has to change for anyone who ships software
TLS protects the channel, not the content. A valid certificate proves that whoever answered controlled the domain at the moment of validation, and a route hijack turns that condition into something a third party can satisfy for a few hours. BGPKIT's conclusion is that once routing is lost, only package signing in the update client separates a network incident from a supply chain compromise. It is the same reasoning we applied to TeamPCP and the trojanised security tooling and to the npm worm that planted hooks in developers' editors. The distribution mechanism is part of the product's attack surface.
For buyers, the question to put to every software supplier with automatic updates is short: does the client verify the package signature before installing, or does it trust HTTPS? That question already featured in our five lessons from the digital supply chain; this incident shows what the wrong answer costs. For vendors, the answer belongs on the roadmap before a customer asks, and hardening the systems that run the panel limits the damage when the answer arrives late.
Nothing in the chain ever examined the package itself, and that is how a backdoor reached root on a hosting provider's hypervisors without a single exploit. Virtualizor has promised package signing; until it ships, every other product whose update client trusts HTTPS is one badly filtered /24 away from the same chain.
On sources and attribution: this article rests on Virtualizor's public advisory, on BGPKIT's independent reconstruction from public routing data and on what operators have told specialist media, with the information available at publication date. That the announcement came from autonomous system AS62390 does not by itself establish who operated it or with what intent, and no mention implies a security failure in the networks or certificate authorities named, whose role was that of an abused mechanism. Impact figures come from the affected parties themselves and may change.
This article is for general guidance. The checks and remediation steps described must be adapted to each environment and are no substitute for forensic analysis where there is evidence of compromise. If you suspect a server is affected, seek specialist support.
