The console used to restore your virtual machines can also hold the credentials needed to reach their backups. Vates has confirmed active exploitation of VSA-2026-062, a critical authentication bypass affecting Xen Orchestra and Xen Orchestra Appliance. Its current advisory, dated 10 November, lists Xen Orchestra 6.9.2 on the stable channel and 6.10.1 on the latest channel as fixed. Teams investigating a compromise need a recovery plan for credentials as well as the console.
What is confirmed, and which version to use
The Hacker News reports that the flaw can grant administrative access and lead to code execution on managed pools or root takeover of XCP-ng nodes. It also explains that the authentication flaw can expose reusable login tokens. This is potential impact; it does not establish that every reachable installation suffered those outcomes.
The initial reporting lists appliance versions 6.9.1 and 6.10.0. Follow the current Vates advisory, which lists 6.9.2 and 6.10.1 instead. Its fixed xo-server packages are 5.211.2 for stable and 5.213.1 for latest; for source installations, Vates recommends updating to the current fixed master. Check the actual package and channel on each instance.
The project's merged fix validates authentication token identifiers before lookup. The public material reviewed here does not establish a victim count, the first exploitation date or whether exploitation preceded the fix. We use the vendor's VSA identifier; it should not be mistaken for a CVE number.
Investigate before trusting the recovery console
Vates warns that missing campaign indicators cannot establish that an instance is clean. It recommends a full reinstall after confirmed compromise and rotation of the secrets the stack uses, including backup access, pool and root credentials, user accounts and OTP material. Refer to the advisory for its current investigation guidance.
For the incident lead, the first practical question is who can establish a trusted recovery environment. Assign that person before issuing replacement credentials. If the compromised console receives the new values while an attacker still controls it, rotation simply delivers another set of credentials to the same place.
Keep an evidence record of which systems were reachable, which accounts were configured there and what access was observed. A credential being present makes it part of the exposure assessment; it does not prove exfiltration. Preserve that distinction in internal updates and notifications.
Make a dependency list for the recovery
Work with the virtualization and backup owners to map each credential to the system that accepts it and the jobs that use it. A backup destination may serve several pools. A shared service account may run both a backup and a verification job. Changing either without an owner can leave a backup looking healthy while the next scheduled operation fails.
- Restrict access to management. Confirm the intended administrative network boundary and remove unintended internet access. Record which instances and channels need the fixed release.
- Separate the recovery environment. Establish trusted administrator devices and a rebuilt or otherwise validated management path through your incident process.
- Inventory passwords and tokens separately. Review reusable login tokens as well as account passwords. Ask the platform owner how each credential is invalidated; do not assume a password change ends every token.
- Rotate at the destination. Change backup and service credentials in the systems that accept them, then configure the trusted consumers. Include any recovery material within the assessed exposure.
- Verify restoration and rejection. Test a representative backup and restore with the replacement configuration, and verify that retired credentials no longer grant access. Use a safe test target and record identifiers and results rather than secret values.
Give each replacement a recipient and an end date
Recovery often brings in people who do not normally administer the platform: an external responder, a storage specialist or an overnight engineer. Give each the narrow access needed for the assigned task. Agree who will remove it and when before sending the credential. Verify requests against your established contact list, especially if a new account appears in the incident channel asking for backup access.
Keep the incident channel useful for coordination. Post the credential owner, transfer status and successful test there, and send the actual value directly to the verified recipient. Avoid attaching a complete configuration export when that person only needs one temporary password. Treat evidence exports as sensitive too, since they can preserve the values you have just retired.
Where Secretus fits in the handover
A Secretus link can deliver a replacement text secret with browser-side encryption and become invalid after expiry or first successful access. Use it from trusted devices once the receiving environment is ready. The credential still needs a lifetime and revocation policy at the destination. Secretus does not patch Xen Orchestra, rebuild hosts, revoke platform tokens or remove copies already obtained by an attacker.