Xen Orchestra EUVD-2026-105088

Requires a valid authenticated session as any low-privileged Xen Orchestra user on a version before 6.9.0 - this is the sole prerequisite and is confirmed by PR:L in the CVSS vector. No special configuration, feature flag, or non-default deployment mode is needed: the user.set API method simply omitted the ownership check, so exploitation works against default configurations by supplying an arbitrary target user id. Limiting factors: the attacker must already hold credentials for the XO instance (no unauthenticated path), and impact is confined to modifying other users' preference data (TOTP secret, xsCredentials, sshKeys) rather than direct data exfiltration; no user interaction by the victim is required.

This is a post-authentication authorization bypass (CWE-639) rated CVSS 5.3/medium. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L) is internally consistent with the description: network-reachable, low attack complexity, requires a low-privileged authenticated session (PR:L - so NOT unauthenticated), no user interaction, no confidentiality loss, and limited integrity/availability impact. No EPSS score, KEV listing, or POC indicator was supplied, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The headline numeric score understates practical impact in one respect: the ability to delete another user's preferences.otp TOTP secret effectively disables that victim's 2FA and, combined with overwriting stored xsCredentials/sshKeys, can facilitate downstream account compromise - an integrity consequence the VC:N/VI:L rating treats conservatively. Net assessment: a genuine but second-stage risk requiring a pre-existing foothold, worth prioritizing on multi-user Xen Orchestra instances yet not an internet-wide emergency given the authentication prerequisite and absence of exploitation signals.

A low-privileged but authenticated Xen Orchestra user invokes the xo-server user.set API, passing an administrator's user id as the target instead of their own. Because the pre-6.9.0 code never checked that the id matched the caller, the attacker deletes the admin's preferences.otp value to strip two-factor authentication, or overwrites the admin's stored xsCredentials and sshKeys. No public exploit code is identified, but the flaw is a trivial API parameter manipulation requiring no special tooling.