- From August 28 to 30, 2026, a Hetzner IP block used by Virtualizor was rerouted via a BGP hijack — the attacker obtained a valid TLS certificate and shipped a tampered update.
- Affected are servers that checked for updates during exactly this window. Virtualizor cannot compile a list, so every Virtualizor server should be treated as needing a check.
- Prepaid-Host is not affected: we run Proxmox, not Virtualizor. You don't need to do anything for your server with us.
What happened
Between roughly 20:57 UTC on August 28 and roughly 06:10 UTC on August 30, the IP block 162.55.80.0/24 was rerouted. The block belongs to Hetzner and is used by Virtualizor for its services. The route was announced by AS62390 (NexonHost Srl) via transit AS6204 (Zet.net / InterKVM Host Srl). The legitimate origin is AS24940 — Hetzner itself. As a result, traffic ended up not at Virtualizor but with the attacker.
The hijack ran in two waves. The first from the evening of August 28 until about 08:50 UTC on August 29, when Hetzner began remediation and the rerouting dropped to zero. After roughly eleven quiet hours, the second wave followed from about 20:00 UTC on August 29 until 06:00 UTC on August 30. At 06:10 UTC the unauthorized route was withdrawn. Routing has been restored since then.
Why no one saw a certificate warning
This is the uncomfortable part. Whoever controls an IP route also controls a certificate authority's automated domain validation. That's exactly what happened here: according to Virtualizor, Let's Encrypt's validation also ran over the hijacked path, and the attacker was consequently issued a technically flawless certificate for Virtualizor's domains.
To the affected servers, everything looked normal: HTTPS, a valid certificate, no warning. The usual "is the padlock closed?" check would not have caught this attack.
A tampered update package was then delivered — to the installations that happened to check for updates during the rerouting window. Virtualizor says this affected a handful of servers rather than its broad user base, but it cannot produce a reliable list: the requests went to the attacker, not to the vendor. Hence the clear directive to treat every Virtualizor server as affected.
Important context: Virtualizor states that no tampered package has been found for its other products so far, but the investigation is still ongoing. This is explicitly not an all-clear for Softaculous or Webuzo.
Running Virtualizor yourself? Here's what to do, in order
Check whether this file exists:
test -e /etc/systemd/system/java-jre-update.service && echo AFFECTED || echo clean
If it exists, your server was affected. Don't just delete it. A deleted file destroys your trail and leaves everything else the attacker set up in place. Contact Virtualizor support.
Reset all API keys in the master panel and restrict API access to fixed IP addresses.
Go through the stored API and SSH keys and remove any you can't account for:
for f in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do echo "== $f"; cat "$f" 2>/dev/null; done
Check scheduled tasks and outbound connections too — not just the keys. A planted package sets up its own way back in.
systemctl list-timers --all; crontab -l; ss -tupn state established
If you logged into the Softaculous customer area during the period in question, change your password and review the account activity. If payment details were entered there, also check your card statement.
Virtualizor provides a check script and has announced a detailed report with a timeline and technical analysis. The manual check above doesn't replace that — it just comes sooner.
Are Prepaid-Host customers affected?
Our infrastructure is not affected. Our virtualization runs on Proxmox, Virtualizor is not in use anywhere on our side, and the file mentioned above does not exist on our systems.
On your own root server you can of course run Virtualizor yourself — that is your machine. If you do, this incident affects you like any other operator, and the checklist above applies to your installation. Get in touch if you would like help working through it.
What to take away from this
It's tempting to write "RPKI would have prevented this." It's not that simple.
Our own networks are signed with ROAs and show up as valid in RPKI validation. But so was the hijacked Hetzner block. A signature only works if the networks along the path actually enforce origin validation and drop invalid announcements. If a transit provider doesn't, the best signature is worthless.
The second lesson applies to anyone who auto-updates software: an update channel that relies solely on TLS and DNS is defenseless against a routing attack — because both building blocks run over the very network that just got hijacked. What would have helped here are signed packages whose signature the client verifies against a hard-coded key. Then it wouldn't matter which server the file came from.
Sources
- Virtualizor, Security Incident – BGP Hijacking, August 31, 2026 — official statement with timeline and remediation steps
- LowEndTalk, URGENT: Virtualizor Compromised (31st Aug) — early reports from the operator community
- RIPE NCC, RIPEstat — routing data and holders of the AS numbers involved; we verified the RPKI status of our own networks there ourselves
