Der französische Hersteller Vates hat am 10. November 2026 eine kritische Sicherheitslücke in Xen Orchestra veröffentlicht, die bereits für Angriffe genutzt wird. Über den Fehler mit der Kennung VSA-2026-062 können Angreifer die Anmeldung an der Verwaltungsoberfläche umgehen und mit Admin-Rechten arbeiten. Weil Xen Orchestra die Virtualisierungsplattform XCP-ng steuert, kann das nach Angaben von Vates bis zur vollständigen Übernahme der Hosts mit Root-Rechten führen. Korrigierte Versionen stehen bereit. Eine CVE-Nummer und einen CVSS-Wert hat die Lücke noch nicht, im Advisory steht dazu am 11. November 2026 „Not available yet“.

Xen Orchestra ist die Weboberfläche, über die sich XCP-ng-Pools, Hosts, virtuelle Maschinen und Backups verwalten lassen. Vates bietet sie als fertige Appliance (XOA) an; der Quellcode liegt offen auf GitHub, und wer möchte, baut Xen Orchestra selbst daraus. Beide Varianten sind betroffen.

Ein leeres Objekt als Anmelde-Token

Die REST-Schnittstelle von Xen Orchestra liest das Cookie authenticationToken aus. Steht darin der Wert j:%7B%7D, wird daraus ein leeres JSON-Objekt {} – das Präfix j: kennzeichnet ein Cookie mit JSON-Inhalt. Die REST-Authentifizierung reicht dieses Objekt an die Token-Prüfung weiter, ohne zu verlangen, dass es eine Zeichenkette ist. Die Token-Datenbank behandelt {} als Abfrage ohne Filter und liefert das erste gespeicherte Token, so das Advisory. Ist es noch nicht abgelaufen, gilt der Angreifer als dessen Besitzer.

Daraus ergeben sich die Bedingungen für den Angriff: Der Angreifer muss die Weboberfläche über das Netz erreichen, und in der Datenbank muss ein gültiges Token liegen. Zugangsdaten braucht er nicht. Nach Angaben von Vates erhält er so Admin-Rechte. Über den Endpunkt /rest/v0/users/me/authentication_tokens kann er anschließend wiederverwendbare Login-Token abholen – und damit später erneut hinein, solange diese gültig sind.

Die Korrektur steckt im Pull Request #10748, den die Entwickler am 10. November 2026 in den Hauptzweig übernommen haben. Xen Orchestra weist seitdem Token-IDs zurück, die keine Zeichenkette oder leer sind, und baut die Datenbankabfrage nur noch aus geprüften Feldern. Als Ursprung des Fehlers nennt der Pull Request eine Codeänderung vom Juni 2022.

Angriffe laufen bereits: Diese Spuren nennt Vates

Laut Advisory nutzt ein Angreifer die Lücke aktiv aus, anfangs von der Adresse 91.211.251.112 (Port 8001) und über einen Onion-Dienst im Tor-Netz. In seiner Ankündigung im XCP-ng-Forum schreibt Vates, man habe erfahren, dass die Lücke bereits angegriffen werde. Sie habe zu diesem Zeitpunkt noch unter Embargo gestanden, der Patch sei deshalb beschleunigt fertiggestellt worden. Entdeckt haben die Schwachstelle Filip Magic und Christoffer Olsen von TDC NET Security.

Die von Vates genannten Indikatoren legen nahe, wie die Angreifer von der Weboberfläche auf die Hosts gelangen. Auf den XCP-ng-Hosts soll nach virtuellen Maschinen gesucht werden, deren Plattform-Parameter hvm_serial auf eine Datei zeigt – die serielle Schnittstelle der VM schreibt dann in eine Datei auf dem Host. Dazu kommen eine VM namens „pivot2“ sowie die Dateien /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 und /.ustar6. Über eine Datei in /etc/cron.d lässt sich ein Befehl mit Root-Rechten starten. Vates lässt außerdem nach /etc/ld.so.preload sehen; über diese Datei lassen sich Bibliotheken in jeden Prozess einschleusen.

Ein wichtiger Satz steht im Advisory selbst: Ein erfolgreicher Zugriff ohne Anmeldung hinterlässt in Xen Orchestra kein Log. Vates rät stattdessen, den HTTP-Verkehr zu überwachen, etwa mit tcpdump oder Wireshark, und nach den Mustern authenticationToken=j:%7B%7D und authenticationToken=j:{} zu suchen. Die Indikatoren decken laut Vates nur die bisher bekannte Kampagne ab; fehlen sie, ist das kein Beweis, dass nichts passiert ist. Passend dazu schildert ein Nutzer im XCP-ng-Forum am 11. November 2026 einen Angriff auf sein Homelab mit anderen Adressen, VM- und Dateinamen als im Advisory; auch dort habe eine VM über ihre serielle Ausgabe eine Cron-Datei auf dem Host angelegt. Unabhängig überprüfen lässt sich der Bericht nicht.

Symbolbild: Rückseite eines Serverracks mit verkabelten Rack-Servern

Bild: Symbolbild – Victorgrigas / Wikimedia Commons, CC BY-SA 3.0

Betroffene Versionen und Updates

Betroffen sind laut Vates alle Xen-Orchestra-Versionen vor 6.9.2 im Kanal „stable“ und vor 6.10.1 im Kanal „latest“ sowie die Appliance XOA. Den Fehler beheben die Pakete xo-server 5.211.2 (stable) und 5.213.1 (latest). Erste Berichte, unter anderem von BleepingComputer, nannten 6.9.1 und 6.10.0 als korrigierte Versionen. Maßgeblich ist das Advisory – und danach sind genau diese beiden Versionen noch verwundbar. Wer Xen Orchestra aus dem Quellcode betreibt, soll auf den aktuellen Stand des Hauptzweigs (master) aktualisieren, der den Fix enthält.

Am selben Tag hat Vates außerdem Sicherheitsupdates für XCP-ng 8.3 LTS veröffentlicht, die mit VSA-2026-062 nichts zu tun haben. Darunter ist eine als kritisch eingestufte Lücke im Toolstack XAPI (XSA-529): Das Pool-Secret, mit dem sich die Hosts eines Pools untereinander ausweisen, wurde mit einer Vergleichsfunktion geprüft, deren Laufzeit vom Inhalt abhängt. Ein Angreifer im Verwaltungsnetz des Pools könnte das Geheimnis so möglicherweise ohne Anmeldung ermitteln. Nach dem Update, für das die Hosts neu starten müssen, empfiehlt Vates, das Pool-Secret mit xe pool-secret-rotate neu zu erzeugen.

Was du jetzt tun solltest

Vates rät dringend, so schnell wie möglich zu aktualisieren.

  1. XOA aktualisieren: In der Oberfläche von XO 5 unter „XOA“ › „Updates“ auf „Upgrade“ klicken. XO 6 verwaltet Updates noch nicht selbst; von dort führt der Link „XO 5“ oben rechts in die richtige Ansicht. Per SSH auf der Appliance geht es mit xoa-updater --upgrade. Ziel ist 6.10.1 (latest) oder 6.9.2 (stable).
  2. Installation aus dem Quellcode aktualisieren, neu bauen und xo-server danach neu starten (Befehle unten). Mit git merge-base prüfst du, ob der Fix in deinem Stand steckt.
  3. Oberfläche abschotten: Xen Orchestra gehört nicht ins offene Internet, sondern hinter ein VPN, in ein eigenes Verwaltungsnetz oder hinter eine IP-Freigabeliste. Vates empfiehlt zusätzlich, die Adressen der Angreifer in beide Richtungen zu sperren und Tor-Verkehr zu blockieren. Ein Filter für das leere Token in einer WAF oder einem Reverse Proxy ist möglich, laut Vates aber mit Vorsicht zu genießen: Andere Schreibweisen können eine solche Regel umgehen.
  4. Spuren prüfen mit den Befehlen aus dem Advisory auf jedem XCP-ng-Host. In Xen Orchestra selbst rät Vates, auf unerwartete VMs, Importe und Sitzungen zu achten; ein Blick in /root/.ssh/authorized_keys und /etc/cron.d/ auf den Hosts schadet ebenfalls nicht.
  5. Sitzungen und Token widerrufen, Geheimnisse erneuern: Das Update verhindert den Trick mit dem leeren Objekt. Token, die Angreifer bereits abgeholt haben, sind aber echte Token und bleiben gültig, bis sie ablaufen oder widerrufen werden. Vates rät deshalb im Forum, alle aktiven Sitzungen und API-Token zu widerrufen und die Geheimnisse der Umgebung zu wechseln. Bei einem Einbruch lässt sich laut Advisory nicht ausschließen, dass Konfiguration und Zugangsdaten abgeflossen sind. Zu erneuern sind demnach Root-Kennwörter aller Hosts, Zugangsdaten für XO-Proxys und Backup-Ziele (NFS, S3, Azure, SMB), Kennwörter und OTP-Geheimnisse der XO-Nutzer, Mailserver-Zugangsdaten und das Pool-Secret. Bei einer bestätigten Kompromittierung empfiehlt Vates eine Neuinstallation, weil Aufräumen nicht garantiere, dass alle Hintertüren verschwinden.

Für Installationen aus dem Quellcode nennt die Dokumentation diese Schritte im Verzeichnis xen-orchestra:

# Achtung: verwirft lokale Änderungen im Arbeitsverzeichnis
git checkout .
git pull --ff-only
yarn
yarn build
# Steckt der Fix aus Pull Request #10748 im aktuellen Stand?
git merge-base --is-ancestor 50166fe3a4 HEAD && echo "Fix enthalten"

Die Prüfbefehle aus dem Advisory für die XCP-ng-Hosts:

# VMs, deren serielle Schnittstelle in eine Datei schreibt
xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'
# Spuren im XAPI-Log
zgrep -- '-serial file:' /var/log/xensource.log*
# Dateien der bekannten Kampagne
ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*

Diese Adressen sollen laut Advisory ein- und ausgehend gesperrt werden:

91.211.251.112
193.148.56.72
37.221.208.216
45.66.35.11
64.65.0.120
64.65.62.160
89.47.51.90
92.60.37.247

Einordnung: Verwaltungsoberflächen gehören nicht ins Netz

Vates betont in seiner Ankündigung, dass die meisten Xen-Orchestra-Installationen nicht aus dem Internet erreichbar seien, was das Risiko deutlich senke. Wessen Oberfläche offen im Netz steht, solle aber dringend handeln. Grundsätzlich gelte für jedes Produkt: Eine Verwaltungsebene für Virtualisierung gehöre nie ins offene Internet, egal wie aktuell sie sei. Ein VPN und ein eigenes Verwaltungsnetz blieben der beste Schutz vor der nächsten unbekannten Lücke. Alle Anweisungen bündelt Vates im Advisory, das aktualisiert werden soll, sobald es neue Erkenntnisse gibt.

Quellen

Bildnachweis