Obejście uwierzytelniania w Xen Orchestra daje dostęp administratora i może prowadzić do przejęcia hostów XCP-ng

Co się wydarzyło

Dnia 10 listopada 2026 r. Vates opublikował komunikat bezpieczeństwa VSA-2026-062 dotyczący krytycznego obejścia uwierzytelniania w Xen Orchestra. Xen Orchestra to webowy interfejs zarządzania środowiskami wirtualizacji XCP-ng. Identyfikator CVE ani wynik CVSS nie zostały jeszcze przypisane.

Błąd dotyczy sposobu, w jaki REST API obsługuje ciasteczko logowania. Ciasteczko o wartości authenticationToken=j:%7B%7D jest parsowane do pustego obiektu ({}). Obiekt ten trafia do sprawdzenia tokenu bez weryfikacji, czy jest to ciąg znaków. Wyszukiwanie tokenu zwraca wówczas pierwszy zapisany token, a żądanie zostaje uwierzytelnione jako właściciel tego tokenu, o ile token nie wygasł. Za pośrednictwem endpointu /rest/v0/users/me/authentication_tokens atakujący może odczytać identyfikatory tokenów logowania, które można ponownie wykorzystać.

Segment Vates wskazuje, że atakujący może dzięki temu wykonywać operacje z uprawnieniami administratora w Xen Orchestra bez danych uwierzytelniających. Może to prowadzić do wykonania dowolnego kodu na zarządzanych pulach i pełnego przejęcia hostów XCP-ng z uprawnieniami root.

Vates informuje, że luka jest aktywnie wykorzystywana przez podmiot zagrożenia działający z adresu 91.211.251.112:8001 oraz z adresu Tor (patrz poniżej). Nie wiadomo, kiedy rozpoczęły się ataki ani czy luka była wykorzystywana przed wydaniem poprawki. Błąd odkryli Filip Magic i Christoffer Olsen z TDC NET Security.

Kogo dotyczy problem

• Xen Orchestra przed wersją 6.9.1 (kanał stable) oraz przed wersją 6.10.0 (kanał latest)
• odpowiednie pakiety xo-server przed wersją 5.211.2 (stable) i 5.213.1 (latest)
• Xen Orchestra Appliance (XOA)

Atakujący potrzebuje dostępu sieciowego do webowego interfejsu Xen Orchestra. Instancje dostępne z internetu są narażone najbardziej. Hosty XCP-ng również są zagrożone, ponieważ zarządza nimi Xen Orchestra. Jeśli nie używasz Xen Orchestra, ten komunikat Cię nie dotyczy.

Co należy zrobić teraz

1. Zaktualizuj Xen Orchestra. Zainstaluj Xen Orchestra 6.9.1 z kanału stable lub 6.10.0 z kanału latest. Zawierają one xo-server 5.211.2 (stable) lub 5.213.1 (latest). Przed aktualizacją należy wykonać kopię zapasową konfiguracji Xen Orchestra. Po aktualizacji warto potwierdzić, że xo-server działa, oraz że możliwe jest zalogowanie się i wyświetlenie pul.
2. Ogranicz dostęp. Nie udostępniaj Xen Orchestra w internecie. Vates zaleca umieszczenie go w dedykowanej sieci zarządzania, do której dostęp mają wyłącznie administratorzy, na przykład przez VPN.
3. Zablokuj infrastrukturę atakującego. Vates zaleca reguły filtrowania ruchu przychodzącego i wychodzącego dla adresu 91.211.251.112 oraz blokowanie ruchu Tor, tak aby hosty nie mogły połączyć się z ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion.
4. Jeśli nie możesz zaktualizować natychmiast, zablokuj pusty token w zaporze WAF lub w reverse proxy przed Xen Orchestra. Dopasuj wzorce ciasteczek authenticationToken=j:{} oraz authenticationToken=j:%7B%7D.
5. Sprawdź, czy nie doszło do kompromitacji (patrz następna sekcja). Jeśli znajdziesz ślady kompromitacji, zmień wszystkie hasła i sekrety używane w środowisku Xen Orchestra i XCP-ng oraz zbadaj dotknięte hosty i maszyny wirtualne.

Jak sprawdzić, czy jesteś narażony

Najpierw sprawdź wersję Xen Orchestra w interfejsie webowym lub na appliance. Jeśli jest starsza niż 6.9.1 (stable) lub 6.10.0 (latest), system jest podatny.

Vates oraz opublikowane raporty wskazują następujące wskaźniki kompromitacji dla znanej kampanii ataków:

• żądania HTTP zawierające authenticationToken=j:%7B%7D lub authenticationToken=j:{}
• połączenia z 91.211.251.112:8001 lub ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333
• maszyna wirtualna o nazwie pivot2
• maszyny wirtualne skonfigurowane z hvm_serial: file
• pliki /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 i /.ustar6

Na hostach XCP-ng należy wykonać kontrole zalecane przez Vates:

xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'

zgrep -- '-serial file:' /var/log/xensource.log*

ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*

Warto również poszukać maszyny wirtualnej o nazwie pivot2, na przykład poleceniem xe vm-list name-label=pivot2.

Segment z raportów wynika, że Xen Orchestra nie zapisuje spreparowanego ciasteczka w logach. Wykrycie jest możliwe wyłącznie przez monitorowanie ruchu HTTP, na przykład w logach dostępu reverse proxy przed Xen Orchestra. Należy sprawdzić te logi oraz logi zapory sieciowej pod kątem wzorców ciasteczek i wymienionych adresów. Vates zwraca uwagę, że wskaźniki dotyczą jednej znanej kampanii. Inni atakujący mogą pozostawiać inne ślady, dlatego brak powyższych wskaźników nie dowodzi, że system jest czysty.

Źródła

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://thehackernews.com/2026/11/hackers-exploit-critical-xen-orchestra.html