BGP-Hijacking Angriff: Manipuliertes Update landet auf echten Servern

Ein BGP-Hijacking Angriff hat über ein Fenster von rund 33 Stunden Datenverkehr des Software-Herstellers Softaculous zu einem fremden Server umgeleitet. Das Ergebnis: Ein manipuliertes Update der VPS-Verwaltung Virtualizor landete auf echten Servern. Der Hersteller hat den Vorfall am 31. August 2026 ungewöhnlich detailliert offengelegt.

Was beim BGP-Hijacking Angriff passiert ist

Laut Analyse von Virtualizor tauchte am 28. August 2026 um 20:57:30 UTC eine unautorisierte Ankündigung für den Adressbereich 162.55.80.0/24 auf — ein Stück Hetzner-Adressraum, in dem unter anderem der Software-Update-Endpunkt und das Kundenportal von Softaculous liefen. Weil diese Ankündigung spezifischer war als Hetzners reguläres 162.55.0.0/16, gewann sie überall dort die Routenauswahl, wo sie ankam. Erst am 30. August gegen 06:10 UTC war der Spuk vorbei.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Der raffinierte Teil steckt im AS-Pfad: Als Ursprung stand weiterhin AS24940 (Hetzner) drin. Der Angreifer AS62390 (NexonHost) hängte sich davor, der Transit lief über AS6204 (Zet.net). Der vom Hersteller genannte Beispielpfad lautet 20912 6204 62390 24940. Wer also nur auf die Origin-AS schaut, sah Hetzner — und damit nichts Verdächtiges.

Dazu kam ein zweiter unangenehmer Effekt: Der Angreifer bekam über die Umleitung ein technisch gültiges TLS-Zertifikat von Let’s Encrypt für die betroffenen Domains, weil auch die automatische Domain-Prüfung der Zertifizierungsstelle durch den Hijack lief. Für Clients sah alles korrekt aus — keine Zertifikatswarnung, kein Alarm.

Virtualizor hat den Verlauf selbst aus öffentlichen RIPE-RIS-Daten rekonstruiert, im Zehn-Minuten-Raster. Danach führte in den aktiven Phasen bei rund 72 Prozent der 368 RIS-Messpunkte der beste Pfad über den Angreifer. Der Hersteller schreibt selbst dazu, das sei ein Maß für Routing-Topologie, kein Traffic-Volumen. Wichtig für die Einordnung: Das 33-Stunden-Fenster war nicht durchgehend aktiv — tatsächlich lief die Umleitung in zwei Wellen über etwa 22 Stunden, dazwischen lagen rund elf Stunden nahezu ohne Umleitung.

Warum ein gültiges Zertifikat hier nichts gerettet hat

Der Hersteller schreibt offen, dass die Update-Clients Pakete nicht kryptografisch signiert geprüft haben. Ein manipuliertes Paket wurde deshalb schlicht nicht zurückgewiesen. Bestätigt ist, dass ein bösartiges Virtualizor-Update an eine kleine Zahl von Installationen ausgeliefert wurde — an jene, deren Update-Prüfung zufällig in ein umgeleitetes Zeitfenster fiel. Zu den Fähigkeiten der Schadsoftware macht Softaculous keine Angaben; als Kompromittierungsindikator nennt der Hersteller eine systemd-Unit unter /etc/systemd/system/java-jre-update.service.

Eine vollständige Liste betroffener Server kann Softaculous nicht liefern, weil die bösartigen Antworten nie durch die eigenen Logs liefen.

Was das für dich bedeutet

Der Fall ist auch dann lehrreich, wenn du kein Virtualizor betreibst. Er zeigt sauber, wo die eigentliche Vertrauensgrenze in einem Update-Mechanismus liegt. Viele Betreiber setzen HTTPS mit Vertraulichkeit und Integrität gleich. Tatsächlich beweist ein gültiges Zertifikat nur, dass jemand die Domain-Kontrolle nachweisen konnte — und die lässt sich mit einem Routing-Hijack erschleichen, weil die Prüfung der Zertifizierungsstelle denselben Weg nimmt wie der Angriff.

Der einzige belastbare Schutz ist deshalb eine Signatur, die unabhängig vom Transportweg funktioniert: Der Client kennt den öffentlichen Schlüssel des Herstellers und verwirft alles, was nicht dazu passt. Genau das kündigt Softaculous jetzt an — nachträglich. Aus meiner Erfahrung mit Update-Ketten in Firmennetzen ist das eine der häufigsten stillen Lücken: Der Übertragungsweg ist verschlüsselt, das Paket selbst ist es nicht.

Die praktische Frage für dein eigenes Netz lautet deshalb: Welche Management-Panels, Agents und Update-Kanäle bei uns prüfen Paketsignaturen — und welche vertrauen nur auf TLS? Bei Betriebssystem-Paketmanagern ist die Antwort meist beruhigend. Bei Herstellersoftware mit eigenem Auto-Update ist sie es oft nicht, und in der Dokumentation steht dazu häufig gar nichts. Wenn nichts dasteht, ist die Antwort erfahrungsgemäß „nein”.

Ein Detail, das in den Meldungen fehlt: RPKI

Die Berichterstattung lässt den Eindruck entstehen, der Hijack sei praktisch überall durchgegangen. Eine eigene Abfrage bei RIPE Stat am 2. September 2026 zeigt ein differenzierteres Bild: Für 162.55.80.0/24 mit Origin AS24940 lautet der RPKI-Status invalid_length. Hetzner hat eine ROA für 162.55.0.0/16 mit maxLength 16 hinterlegt — jede spezifischere /24 aus diesem Block verletzt damit die ROA, selbst wenn die Origin-AS korrekt gefälscht wurde.

Netze, die konsequent „RPKI invalid = drop” umsetzen, hätten die Hijack-Route also verworfen. Wichtige Einschränkung, die man dazusagen muss: Gemessen wurde der heutige ROA-Stand, nicht der Stand während des Vorfalls. Das ist ein starkes Indiz, kein Beweis. Für die Praxis bleibt die Lehre aber gültig — Route Origin Validation beim eigenen Transit-Provider nachzufragen, lohnt sich.

Konkrete Handlungsempfehlung

• Wenn du Virtualizor betreibst: Prüfe sofort, ob /etc/systemd/system/java-jre-update.service existiert. Falls ja — nicht löschen, sondern erst den Hersteller kontaktieren, damit Spuren erhalten bleiben.
• API-Keys rotieren und den API-Zugriff auf vertrauenswürdige IP-Adressen einschränken. Unbekannte Keys entfernen. Auch die Keys im Softaculous-Kundenbereich neu erzeugen.
• Server auditieren: unbekannte SSH-Keys, neue Benutzerkonten, unerwartete Cronjobs und ausgehende Verbindungen.
• Passwort für das Kundenportal ändern, wenn du dich zwischen 28. August 20:57 UTC und 30. August 06:10 UTC dort angemeldet hast — und dasselbe Passwort überall dort, wo du es wiederverwendet hast.
• Prüfskripte mit Verstand einsetzen: Der Hersteller bietet ein Scan-Skript an. Es liegt auf genau der Infrastruktur, die gerade umgeleitet wurde — vor dem Ausführen also anschauen, statt es blind in eine Shell zu pipen.
• Für eigene Infrastruktur: Frag deinen Provider nach RPKI-Origin-Validierung und nach dem maxLength-Wert deiner eigenen ROAs.

Wer eigene Dienste zu Hause oder im Rechenzentrum betreibt, findet in unserem Ratgeber zu NAS und Heimserver fürs Selfhosting die Hardware-Seite dazu. Und wie schnell aus einer Entwickler- oder Verwaltungsplattform ein Angriffsweg wird, hatten wir zuletzt bei der Gitea-Sicherheitslücke.

Einordnung

Positiv hervorzuheben ist die Offenlegung selbst. Virtualizor veröffentlicht eine Zeitleiste mit Messdaten, benennt das fehlende Code-Signing als eigenes Versäumnis und hat mit Virtualizor 3.2.9.9 am 1. September eine Version mit einem Security-Analyzer im Admin-Panel nachgeschoben. Solche Berichte sind selten und für andere Betreiber wertvoller als jede Pressemitteilung.

Zwei Dinge sollte man trotzdem nüchtern sehen. Erstens: Die Kritik an Hetzner, man sei nicht proaktiv informiert worden, ist die Darstellung einer Seite. Eine Stellungnahme von Hetzner liegt in keiner der Meldungen vor. Zweitens: Da die Angreifer-Antworten nie in den Logs des Herstellers landeten, ist „nur eine kleine Zahl betroffen” eine begründete Einschätzung, kein Nachweis. Für die eigene Risikobewertung heißt das: im Zweifel prüfen, nicht auf die Statistik hoffen.

Quellen

• Virtualizor: Security Incident – BGP Hijacking (31. August 2026, Primärquelle mit Messdaten und Zeitleiste)
• Virtualizor: Release-Post zu Patch 9 mit Security Analyzer (1. September 2026)
• BleepingComputer: Hackers push malicious Virtualizor update in BGP hijacking attack
• The Register: 33-hour BGP hijack of Softaculous traffic prompts security scramble
• RIPE Stat: RPKI-Validierung für 162.55.80.0/24 (eigene Abfrage, 2. September 2026)