One Cookie, Full Control: Responding to the Xen Orchestra Auth Bypass (VSA-2026-062)

What this session covers

Xen Orchestra is the management plane for XCP-ng and XenServer pools. Whoever controls it controls every virtual machine underneath: snapshots, exports, console access, new VMs. VSA-2026-062 is an authentication bypass in that management plane, and the public reporting says it was exploited before the fix was available. In this session we rebuild the situation in our isolated lab and go through the response the way we would run it for a client.

The session is structured as five steps. We start with the only question that matters in the first ten minutes: is the Xen Orchestra interface reachable from the internet, and from where? We then look at the version trap: two release trains were fixed in parallel, and a version number that looks recent can still be vulnerable. The third and fourth steps are the hunt, first on the Xen Orchestra server itself and then on the hosts, where the artifacts of a control-plane compromise actually land. The last step is the lockdown, and we close with a short checklist you can run today.

Key takeaways

• Exposure first. Confirm whether the Xen Orchestra web interface is reachable from the public internet before anything else. A control plane that is only reachable through a VPN or a management network changes the whole risk picture.
• Do not trust the version number alone. Fixed builds exist on two trains. Check the exact xo-server version against the advisory, not just the major release.
• Hunt on the server and on the hosts. Authentication logs, new or modified users and tokens, unexpected sessions and API calls on the Xen Orchestra side; new VMs, exports, snapshots and console sessions on the pool side.
• Lock it down in order. Patch, remove the public exposure, rotate every credential and token that touched the management plane, then review what the compromised sessions could have reached.
• Keep the advisory open. The vendor advisory is the source of truth for affected and fixed versions and is linked above.

About the lab

Everything in the video runs on a disconnected lab environment. No exploit is shown or discussed in reproducible detail. The IP addresses and the onion address that appear on screen are the publicly reported indicators from the advisory thread, shown so that defenders can search their own logs for them. Credit for the discovery goes to Filip Magic and Christoffer Olsen of TDC NET Security.