XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    89 vulnerabilities in XAPI / Citrix XenServer

    Scheduled Pinned Locked Moved Development
    2 Posts 2 Posters 35 Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H Online
      hoerup
      last edited by

      https://shittrix.moksha.dk/

      Just saw this one

      1 Reply Last reply Reply Quote 0
      • stormiS Online
        stormi Vates 🪐 XCP-ng Team
        last edited by stormi

        Hi.

        We are aware of this publication and have reviewed every of its claims over the last days.

        A few of the reported issues do represent real privilege escalation paths. However, they rely on XAPI’s advanced RBAC roles feature, which is not enabled or exposed by default in Xen Orchestra, XO Lite, or any of our standard documentation. In practice, the escalation path requires a specific setup: an XCP-ng pool connected to Active Directory for its user management, where a user is given access to the management network and is explicitly granted VM configuration rights (vm-admin XAPI role) via XAPI roles. Such a user could gain elevated host-level privileges beyond what was intended.

        As we don't actively promote or recommend this configuration, we believe very few users are using it. For the small group that might be, patched packages are in the testing phase, and we will release them shortly.

        CVEs are being assigned by the Xen Project (which is the parent project of the XAPI Project) to the vulnerabilities, all requiring this vm-admin XAPI role.

        Most of the other claims stem from misunderstandings of how XAPI roles are designed to work (~65 of the 89 claims), or describe bugs that don’t translate to actual security impact (~15 of them).

        On the disclosure process: we always appreciate coordinated security research, but responsible disclosure typically involves a reasonable grace period (often two weeks or more) to allow time for review, patching, and coordinated release. In this case, we received an email just 24 hours before public publication, and the initial contact came with strange conditions. That doesn’t align with standard responsible disclosure practices.

        Note: This is not intended as an official statement. I have a clear view of the security impact, but since this is an informal, unfiltered write-up, please pardon any minor mistakes in how I’ve reported it.

        1 Reply Last reply Reply Quote 3

        Hello! It looks like you're interested in this conversation, but you don't have an account yet.

        Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

        With your input, this post could be even better šŸ’—

        Register Login
        • First post
          Last post