--- title: "Xen Orchestra: Angreifer umgehen Anmeldung per leerem Token, Vates patcht" date: 2026-11-10T19:17:14+01:00 modified: 2026-11-10T19:17:14+01:00 category: sicherheit type: news author: Marcel Schönfelder canonical: https://s-edv.com/news/xen-orchestra-vsa-2026-062-auth-bypass-aktiv-ausgenutzt keywords: - Xen Orchestra - Vates - XCP-ng - VSA-2026-062 - Authentifizierung - Virtualisierung - Aktiv ausgenutzt reading_time: 4 --- # Xen Orchestra: Angreifer umgehen Anmeldung per leerem Token, Vates patcht Vates hat am 10. November 2026 das Advisory VSA-2026-062 zu einer kritischen Lücke in Xen Orchestra veröffentlicht, der Weboberfläche zur Verwaltung von XCP-ng-Pools. Über ein präpariertes Cookie lässt sich die Anmeldung umgehen. Laut Vates wird die Lücke bereits aktiv ausgenutzt. Behoben ist sie in xo-server 5.213.1 (Kanal „latest“, Xen Orchestra 6.10.0) und 5.211.2 (Kanal „stable“, Xen Orchestra 6.9.1). Betroffen sind laut Vates die Xen Orchestra Appliance (XOA) und xo-server vor den korrigierten Versionen, damit auch Installationen aus den Quellen ohne den Fix. Wer Xen Orchestra einsetzt, sollte heute aktualisieren und prüfen, ob die Oberfläche aus dem Internet erreichbar ist. Eine CVE-Nummer und einen CVSS-Wert gibt es noch nicht. ## Was ist passiert? Laut Advisory wandelt die REST-Schnittstelle das Cookie `authenticationToken=j:%7B%7D` in ein leeres Objekt um. Dieses Objekt reicht Xen Orchestra ungeprüft an die Token-Suche weiter. Die Suche behandelt es wie eine Abfrage ohne Filter und liefert das erste gespeicherte Token zurück. Ist es noch gültig, meldet Xen Orchestra den Angreifer als Besitzer dieses Tokens an. Über die Route `/rest/v0/users/me/authentication_tokens` kommt er anschließend an weitere, wiederverwendbare Login-Tokens. Den Fix hat Vates am 10. November in den Hauptzweig auf GitHub übernommen (Pull Request 10748). Er weist leere und nicht als Zeichenkette übergebene Token-IDs ab, und zwar in der REST-API, bei `/signin` und beim JSON-RPC-Aufruf `session.signIn`. Entdeckt haben die Lücke laut Vates Filip Magic und Christoffer Olsen von TDC NET Security. ## Wer ist betroffen? Betroffen ist xo-server vor den Versionen 5.213.1 und 5.211.2. Wichtig für die Prüfung: Die Versionsnummern 6.10.0 und 6.9.1 gab es schon vorher, laut Changelog mit xo-server 5.213.0 und 5.211.1. Vates hat beide Stände am 10. November aktualisiert. Maßgeblich ist deshalb die Version von xo-server, nicht die Nummer von Xen Orchestra. Wer Xen Orchestra aus den Quellen baut, braucht den aktuellen Stand des Hauptzweigs ab Commit 50166fe3a. Ein Release mit dem Fix war auf GitHub am 10. November noch nicht veröffentlicht. ## Wie kritisch ist das? Vates stuft die Lücke als kritisch ein. Laut Advisory kann ein Angreifer die Anmeldung umgehen und Aktionen mit Admin-Rechten ausführen. Nötig ist dafür laut BleepingComputer nur Netzzugang zur Oberfläche. Über Xen Orchestra lässt sich dann Code auf den verwalteten Pools ausführen und ein XCP-ng-Host als root übernehmen. Mit welchen Rechten der Angreifer landet, hängt nach der beschriebenen Mechanik davon ab, wem das erste gültige Token gehört. Das ist eine Schlussfolgerung aus dem Advisory, Vates selbst schränkt die Admin-Rechte nicht ein. Zur Ausnutzung schreibt Vates, ein Angreifer operiere von der Adresse 91.211.251.112 (Port 8001) und über einen Tor-Dienst aus. Eine erfolgreiche Anmeldung über die Lücke hinterlässt laut Vates keinen Logeintrag. ## Was sollten Admins jetzt tun? - Inventar: alle Xen-Orchestra-Instanzen erfassen und die Version von xo-server ablesen, nicht nur die Nummer von Xen Orchestra. - Update: XOA im Kanal „latest“ auf xo-server 5.213.1, im Kanal „stable“ auf 5.211.2 bringen. Installationen aus den Quellen auf den aktuellen Hauptzweig aktualisieren und neu bauen. - Erreichbarkeit: Xen Orchestra nicht ins Internet stellen, sondern in ein eigenes Management-Netz verlegen, wie Vates empfiehlt. - Sperren: Verkehr zu und von 91.211.251.112 sowie Tor-Verkehr blockieren. Ein Filter für das leere Token in WAF oder Reverse Proxy hilft nur übergangsweise, laut Vates lässt er sich mit anderen Schreibweisen umgehen. - Spuren suchen: in laufenden VMs nach einer VM namens „pivot2“ suchen, auf den XCP-ng-Hosts nach VMs mit dem Parameter `hvm_serial: file` und nach den Dateien `/etc/cron.d/zz-ustar`, `/etc/cron.d/zz-ustar2`, `/.ustar5` und `/.ustar6`. Im Netzwerkmitschnitt verraten die Cookie-Muster `authenticationToken=j:%7B%7D` und `authenticationToken=j:{}` den Angriff. - Nach einem Fund: alle Passwörter und Geheimnisse wechseln, die Xen Orchestra nutzt, etwa für Proxys, Backups, S3-Ziele, root und Benutzerkonten. ## Einordnung für Unternehmen Xen Orchestra hält die Schlüssel zur gesamten Virtualisierung. Wer die Oberfläche übernimmt, kann laut Vates Code auf den verwalteten Pools ausführen. Damit sind auch die VMs und die Zugänge zu Backups in Gefahr. Die Indikatoren decken laut Vates nur diese eine Kampagne ab. Fehlen sie, ist eine Kompromittierung also nicht ausgeschlossen. Seit wann die Lücke ausgenutzt wird, nennt Vates nicht. Wer Xen Orchestra offen im Netz betrieben hat, sollte nach Einschätzung der Redaktion die Zugangsdaten deshalb auch ohne Fund wechseln und die Hosts genauer prüfen. ## Passende Anleitungen auf S-EDV - [Xen XSA-526 bis XSA-528: Gäste können Host über Linux-Backends abstürzen lassen](https://s-edv.com/news/xen-xsa-526-527-528-netback-blkback-host-absturz) - [Xen-Lücke XSA-523: Bösartige VM liest und schreibt Speicher von Host und Gästen](https://s-edv.com/news/xen-xsa-523-grant-copy-vm-ausbruch) ## Quellen - [Vates: Advisory VSA-2026-062](https://docs.vates.tech/security-advisories/advisories/2026/vates-sa-2026-062/) - [GitHub: Pull Request 10748 mit dem Fix](https://github.com/vatesfr/xen-orchestra/pull/10748) - [GitHub: Changelog von Xen Orchestra](https://raw.githubusercontent.com/vatesfr/xen-orchestra/master/CHANGELOG.md) - [BleepingComputer: Bericht zur ausgenutzten Lücke](https://www.bleepingcomputer.com/news/security/critical-xen-orchestra-auth-bypass-flaw-exploited-to-hijack-vm-servers/)