- Vom 28. bis 30. August 2026 wurde ein von Virtualizor genutzter Hetzner-IP-Block per BGP-Hijack umgeleitet — der Angreifer erhielt ein gültiges TLS-Zertifikat und lieferte ein manipuliertes Update aus.
- Betroffen sind Server, die genau in diesem Fenster nach Updates gesucht haben. Virtualizor kann keine Liste erstellen, deshalb gilt jeder Virtualizor-Server als zu prüfen.
- Prepaid-Host ist nicht betroffen: wir setzen Proxmox ein, kein Virtualizor. Für deinen Server bei uns musst du nichts tun.
Was passiert ist
Zwischen dem 28. August gegen 20:57 UTC und dem 30. August gegen 06:10 UTC wurde der IP-Block 162.55.80.0/24 umgeleitet. Der Block gehört zu Hetzner und wird von Virtualizor für seine Dienste genutzt. Angekündigt wurde die Route von AS62390 (NexonHost Srl) über den Transit AS6204 (Zet.net / InterKVM Host Srl). Der legitime Ursprung ist AS24940, also Hetzner selbst. Der Verkehr landete damit nicht bei Virtualizor, sondern beim Angreifer.
Der Hijack lief in zwei Wellen. Die erste vom Abend des 28. August bis etwa 08:50 UTC am 29. August, als Hetzner mit der Entstörung begann und die Umleitung auf null fiel. Nach rund elf ruhigen Stunden folgte die zweite Welle von etwa 20:00 UTC am 29. August bis 06:00 UTC am 30. August. Um 06:10 UTC wurde die unberechtigte Route zurückgezogen. Das Routing ist seitdem wiederhergestellt.
Warum niemand eine Zertifikatswarnung gesehen hat
Das ist der unangenehme Teil. Wer die Kontrolle über eine IP-Route hat, kontrolliert auch die automatische Domain-Prüfung einer Zertifizierungsstelle. Genau das ist hier passiert: Laut Virtualizor lief die Validierung von Let's Encrypt ebenfalls über den gekaperten Weg, und der Angreifer bekam daraufhin ein technisch einwandfreies Zertifikat auf die Domains von Virtualizor ausgestellt.
Für die betroffenen Server sah alles normal aus: HTTPS, gültiges Zertifikat, kein Warnhinweis. Die übliche Kontrolle „ist das Schloss zu?" hätte diesen Angriff nicht aufgedeckt.
Ausgeliefert wurde daraufhin ein manipuliertes Update-Paket — an die Installationen, die zufällig während der Umleitung nach Updates gesucht haben. Virtualizor spricht von einer Handvoll Server statt der breiten Nutzerbasis, kann aber keine belastbare Liste erstellen: die Anfragen gingen an den Angreifer, nicht an den Hersteller. Daher die klare Ansage, jeden Virtualizor-Server als betroffen zu behandeln.
Wichtig für die Einordnung: Virtualizor schreibt, man habe für andere Produkte des Hauses bislang kein manipuliertes Paket gefunden, die Untersuchung laufe aber noch. Entwarnung für Softaculous oder Webuzo ist das ausdrücklich nicht.
Betreibst du Virtualizor? Dann der Reihe nach
Prüfe, ob diese Datei existiert:
test -e /etc/systemd/system/java-jre-update.service && echo BETROFFEN || echo sauber
Existiert sie, war dein Server betroffen. Lösch sie nicht einfach. Eine gelöschte Datei nimmt dir die Spur und lässt alles andere stehen, was der Angreifer eingerichtet hat. Wende dich an den Virtualizor-Support.
Setz im Master-Panel alle API-Schlüssel zurück und beschränke den API-Zugriff auf feste IP-Adressen.
Geh die hinterlegten API- und SSH-Schlüssel durch und entferne jeden, den du nicht zuordnen kannst:
for f in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do echo "== $f"; cat "$f" 2>/dev/null; done
Sieh dir geplante Aufgaben und ausgehende Verbindungen an — nicht nur die Schlüssel. Ein untergeschobenes Paket richtet sich seinen Rückweg selbst ein.
systemctl list-timers --all; crontab -l; ss -tupn state established
Hast du dich im fraglichen Zeitraum im Kundenbereich von Softaculous angemeldet, änder das Passwort und sieh die Kontoaktivität durch. Wurden dort Zahlungsdaten eingegeben, kontrollier zusätzlich die Kartenabrechnung.
Virtualizor stellt ein Prüfskript bereit und hat einen ausführlichen Bericht mit Zeitleiste und technischer Analyse angekündigt. Die Handprüfung oben ersetzt das nicht — sie kommt nur früher.
Sind Prepaid-Host-Kunden betroffen?
Unsere Infrastruktur ist nicht betroffen. Die Virtualisierung läuft bei uns auf Proxmox, Virtualizor ist bei uns nirgends im Einsatz, und die genannte Datei existiert auf unseren Systemen nicht.
Auf einem eigenen Rootserver kannst du Virtualizor natürlich selbst betreiben — das ist deine Maschine. Tust du das, betrifft dich der Vorfall wie jeden anderen Betreiber, und die Liste oben gilt für deine Installation. Melde dich, wenn du beim Durchgehen Unterstützung brauchst.
Was man daraus mitnehmen sollte
Es liegt nahe, jetzt „RPKI hätte das verhindert" zu schreiben. So einfach ist es nicht.
Unsere eigenen Netze sind mit ROAs signiert und werden in der RPKI-Prüfung als gültig ausgewiesen. Der gekaperte Hetzner-Block war das aber ebenfalls. Eine Signatur wirkt nur, wenn die Netze auf dem Weg die Ursprungsvalidierung auch durchsetzen und ungültige Ankündigungen tatsächlich verwerfen. Tut ein Transit das nicht, nützt die beste Signatur nichts.
Die zweite Lehre trifft jeden, der Software automatisch aktualisiert: Ein Update-Kanal, der sich allein auf TLS und DNS verlässt, ist gegen einen Routing-Angriff wehrlos — weil beide Bausteine über dasselbe Netz laufen, das gerade entführt wurde. Was hier geholfen hätte, sind signierte Pakete, deren Signatur der Client gegen einen fest hinterlegten Schlüssel prüft. Dann ist es gleichgültig, von welchem Server die Datei kam.
Quellen
- Virtualizor, Security Incident – BGP Hijacking, 31. August 2026 — offizielle Stellungnahme mit Zeitleiste und Prüfschritten
- LowEndTalk, URGENT: Virtualizor Compromised (31st Aug) — erste Meldungen aus der Betreiber-Community
- RIPE NCC, RIPEstat — Routing-Daten und Halter der beteiligten AS-Nummern; die RPKI-Angaben zu unseren Netzen haben wir dort selbst geprüft
