Xen Orchestra: ausgenutzte Authentifizierungslücke verschafft Admin-Rechte über die XCP-ng-Virtualisierung

Top-Secured Cyber-Monitoring: unabhängige Analyse auf Grundlage der unten genannten Quellen. Top-Secured ist mit den genannten Unternehmen nicht verbunden und wird Sie niemals nach Bankdaten oder Passwörtern fragen.

Vates hat eine kritische Lücke in Xen Orchestra behoben, der Weboberfläche zur Verwaltung von XCP-ng-Hosts, und meldet, dass sie bereits ausgenutzt wird. Ein präpariertes Cookie genügt, um sich ohne Passwort als bestehender Benutzer auszugeben, meist als Administrator. Die Versionen 6.9.2 und 6.10.1 schließen sie; exponierte Konsolen müssen zudem auf eine Kompromittierung geprüft werden.

Was passiert ist

Am 10. November 2026 veröffentlichte das französische Unternehmen Vates, Hersteller von Xen Orchestra und XCP-ng, die als kritisch eingestufte Sicherheitsmeldung VSA-2026-062 und erklärt, dass die Lücke aktiv ausgenutzt wird. Eine CVE-Kennung oder ein CVSS-Wert lag bei Veröffentlichung nicht vor. Die korrigierten Versionen erschienen am selben Tag.

Der Fehler steckt in der Authentifizierung der REST-API. Ein Cookie, dessen Token ein präpariertes leeres Objekt statt einer Zeichenkette ist, gelangt ungeprüft zur Token-Suche. Diese liefert dann das erste gültige Token, das Xen Orchestra gespeichert hat, und die Anfrage gilt als von dessen Besitzer stammend. Danach kann der Angreifer wiederverwendbare Login-Tokens auflisten und mit Administratorrechten handeln. Der auf GitHub eingespielte Fix weist jedes Token zurück, das keine nicht-leere Zeichenkette ist.

Wer gefährdet ist

Alle Xen-Orchestra-Installationen vor 6.9.2 (Kanal stable) und 6.10.1 (Kanal latest), ob XOA-Appliance oder aus den Quellen gebaut. Laut Vates kann die Übernahme der Konsole zur Codeausführung auf den verwalteten Pools und zu Root-Zugriff auf XCP-ng-Hosts führen. Aus dem Internet erreichbare Konsolen stehen an erster Stelle.

Was jetzt zu tun ist

1. Aktualisieren: XOA auf 6.9.2 (stable) oder 6.10.1 (latest), also xo-server 5.211.2 oder 5.213.1; Installationen aus den Quellen auf den neuesten Commit von master, dann neu bauen.
2. Konsole vom Internet nehmen: nur über ein eigenes Verwaltungsnetz oder VPN.
3. Filtern: die in der Meldung genannten IP-Adressen und die Tor-Adresse sperren und am Reverse Proxy Anfragen blockieren, deren Cookie authenticationToken mit j: beginnt. Vates warnt, dass andere Kodierungen eine solche Regel umgehen können.
4. Nach Spuren suchen: Ein erfolgreicher Angriff hinterlässt keinen Eintrag im Authentifizierungsprotokoll. Suchen Sie nach einer VM namens pivot2 und führen Sie auf jedem XCP-ng-Host xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file', zgrep -- '-serial file:' /var/log/xensource.log* und ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar* aus.
5. Bei Kompromittierung: alle der Plattform bekannten Geheimnisse ändern (Root-Konten, Pool-Secret, Backup-Ziele, Proxys, Benutzer, OTP-Secrets, Mailserver) und, wie Vates empfiehlt, neu installieren statt bereinigen.

Unsere Einschätzung

Die Konsole eines Hypervisors hält die Schlüssel zu allen virtuellen Maschinen: Sie ist der sensibelste Server im Unternehmen und gehört nicht ins Internet. Patchen allein reicht diesmal nicht: Da der Angriff keine Login-Spur hinterlässt, zeigt nur eine Prüfung der Hosts, ob schon jemand drin war.

Quellen

• Vates — VSA-2026-062: Empty-object login token
• GitHub (vatesfr/xen-orchestra) — fix(xo-server): validate authentication token IDs, PR #10748
• The Hacker News — Hackers Exploit Critical Xen Orchestra Auth Bypass Flaw to Gain Admin Access

Wie wir unsere Analysen auswählen, prüfen und schreiben →