BGP Hijack Won a Valid Certificate, Then Root Access

A 33-Hour Hijack of Softaculous's Own Traffic

Between 20:57 UTC on August 28 and 06:10 UTC on August 30, 2026, an attacker hijacked BGP routing for a block of Hetzner-hosted IP addresses belonging to Softaculous, the company behind the widely used Virtualizor VPS control panel. The rogue network AS62390, operating under the name NexonHost, announced a more specific route for the 162.55.80.0/24 block than Hetzner's own advertisement. Softaculous relies on Hetzner for the infrastructure behind Virtualizor's licensing, update, and download servers, which is what made the hijacked block valuable to an attacker in the first place.

Under standard BGP route-selection rules, the more specific route wins wherever it's accepted, so traffic bound for Softaculous's servers was redirected to the attacker's infrastructure for roughly 33 hours. BleepingComputer and The Register both reported the hijack on September 1, 2026, and Softaculous later confirmed the timeline and technical details in its own incident post-mortem. Cybersecuritynews.com and GBHackers published corroborating coverage the same day, describing the hijack as a textbook case of a more-specific-prefix attack against a hosting provider's address space.

Why the Certificate Never Triggered a Warning

The hijack didn't just reroute traffic; it captured the domain-validation checks that Let's Encrypt uses to confirm who controls a domain, and that let the attacker request and receive a real, validly signed TLS certificate for the hijacked domain. Connections to the attacker's server showed no certificate warning at all, because as far as the certificate authority could tell, the request came from the domain's legitimate owner. Nothing in the browser padlock, the certificate chain, or the connection itself signaled that anything was wrong.

That's the uncomfortable part of this incident: Let's Encrypt's automated validation worked exactly as designed. It checks that whoever answers at an IP address controls the domain, and during the hijack window, the attacker genuinely did answer at that address. The forgery wasn't in the certificate; it was in the routing that decided who got to prove ownership. That distinction matters: strengthening domain-validation checks alone won't prevent a repeat, since the weakness sits in the routing layer beneath them.

An Update Client That Never Checked a Signature

A malicious Virtualizor update package went out to a small number of installations, specifically the ones that happened to check for updates during the hijack window, not to Virtualizor's user base at large. Virtualizor's own update client doesn't cryptographically verify the packages it downloads, so a valid certificate on a hijacked route was enough to get attacker-controlled code running as root on affected servers. Virtualizor is used to manage a large share of budget and mid-tier VPS hosting worldwide, which is why even a narrow, time-boxed compromise drew attention from multiple security outlets.

The payload installed unauthorized SSH keys and a fake systemd service disguised as java-jre-update.service, giving the attacker a persistent backdoor that would survive a reboot and look, at a glance, like a routine Java update. Softaculous shipped a patched release, Virtualizor 3.2.9.9, on September 1, 2026, alongside its own writeup of the incident. The company's advisory recommends checking for both the rogue SSH keys and the disguised service by name, since the backdoor was built to blend in with legitimate system processes.

What EU Operators Owe Under NIS2

For any EU or UK operator running infrastructure on Hetzner or another European host, the practical lesson is that a valid HTTPS certificate is not proof of authenticity when the routing beneath it can be spoofed. Hetzner's own route announcement stayed correct throughout the incident; the compromise sat entirely in the traffic that chose the attacker's more specific route instead. An auto-update mechanism that doesn't verify signatures is a single point of failure, no matter how solid the surrounding infrastructure is. The same logic applies beyond Virtualizor, to any product that fetches and installs code automatically without checking a cryptographic signature.

Recommended remediation for anyone running Virtualizor, or any vendor's auto-update client without signature verification, is straightforward: rotate and restrict API credentials, and audit servers for unauthorized SSH keys, accounts, scheduled tasks, and outbound connections. Under NIS2, EU businesses that depend on third-party software for critical infrastructure carry supply-chain due-diligence obligations, and an incident where the vendor's own update channel became the attack vector falls squarely inside that obligation. Operators who treat this as a vendor's problem to fix quietly, rather than a supply-chain risk to document and act on, are the ones most likely to repeat it.

Why We Do This

We do this for everyone trying to keep up with what technology is doing to our lives. The people who build it, and the people it happens to. The Servola Journal exists so that what we learn belongs to all of them.

Nobody pays us for this. No ads, no paywall, free to everyone. We just believe that understanding what's happening to all of us shouldn't depend on who can afford to pay for it.

If it gave you something today, tell us to keep going. Follow us, leave a like, or write a positive comment. We read every one, and they are what keeps us going.

Read next: EU Security Teams Have No Say Over OpenAI's Astra  |  Exploited Weeks Before PaperCut Ever Patched