Vates reports active exploitation of an authentication bypass in Xen Orchestra, the management server for XCP-ng virtual machines. An attacker who can reach its management interface may be logged in as the owner of an existing, unexpired token. Vates says that can grant administrator access and lead to command execution on managed hosts as root.

Update: November 10, 17:42 EST — corrected release versions

Vates revised its advisory after our earlier capture. The fixed Xen Orchestra releases are now listed as stable 6.9.2 and latest 6.10.1, not 6.9.1 and 6.10.0 as this page previously said. The fixed xo-server packages remain stable 5.211.2 and latest 5.213.1. Check both the installed channel and actual package; do not rely on our earlier release numbers. Vates now recommends full reinstallation after a confirmed compromise because cleanup may leave backdoors.

Evidence status: vendor-reported attacks, not merely a laboratory demonstration. Vates names infrastructure and traces from one observed campaign. It does not publish a victim count or establish that every vulnerable installation was attacked. Lawrence Abrams reported the advisory for BleepingComputer on November 10.

Who needs to act

Vates identifies Xen Orchestra and Xen Orchestra Appliance as affected. The flaw is in the REST authentication path: a request can supply an object where a token string is expected. A token lookup can then return an existing token, allowing the request to run under its owner’s privileges. This requires network access to the management service and an unexpired token for that lookup to succeed; the attacker need not supply a valid credential.

Vates’s November 10 advisory assigns this issue VSA-2026-062. It does not yet give a CVE identifier or CVSS score. Check the installed release channel and package against the fixes below.

  • Stable: Xen Orchestra 6.9.2 includes fixed xo-server 5.211.2.
  • Latest: Xen Orchestra 6.10.1 includes fixed xo-server 5.213.1.

These are Vates’s listed fixes, available on both channels as of November 10. Update promptly. Keep Xen Orchestra on a dedicated management network rather than exposing it to the internet. Blocking a known attacker address can interrupt that campaign, but is no substitute for the update or network isolation.

Check managed hosts, not just the web login

Vates publishes indicators for its observed campaign, including an unexpected VM named pivot2, modified VM serial settings and unusual host files. Its detection section has the precise indicators. Preserve available HTTP request records and host evidence if investigating suspected access. The vendor warns that a successful bypass may leave no unauthenticated-access event in application logs. Missing its published indicators does not clear a host.

If compromise is suspected, investigate the manager and managed XCP-ng pools together. Vates advises rotating the passwords and secrets used by the virtualization environment after compromise, including backup, proxy, object-storage and host credentials. After confirmed compromise, Vates recommends full reinstallation. Coordinate recovery with an incident-response team before treating an updated management server as a clean environment.

Caveat: The exploitation account and indicators come from Vates, the affected vendor; the advisory limits its detection examples to the campaign it observed.