Offline
We pushed the updates to the xcp-ng-updates repository: https://xcp-ng.org/blog/2026/05/21/may-2026-updates-3-for-xcp-ng-8-3-lts/
Changed since the initial announcement, xen was updated with the proper vulnerability fix and an update to sm was added to fix an issue on LVM-based SRs with CBT enabled.
Thanks everyone for your feedback!
Indeed we only list source packages. xapi's source RPM alone creates a lot of RPMs each time, for example. In this case, all those with version 26.1.4-3.1.xcpng8.3.
Ping @Team-Storage again, about the last comment.
@andrewperry We're preparing a release of the workaround script that our developers made.
As for the proper fix, it's actually more complex that it may seem, and developers have been working on it for a few months already. If I understood correctly, it's related to the way VDI snapshots are reverted, with responsibilities shared between the storage stack and XAPI, the fixes requiring deep changes in both stacks.
So far no reply to that question but I only asked earlier today. I presume it is a complex technical question that cannot be answered without discussion with upstream Xen developers.
Actually I think Stormi is just extremely busy.
I'm pretty sure core isolation requires nested virtualization and thus is not supported at the moment.
XenServer developers recently contributed a patch series that removes a bit of technical debt from Xen, doing which was one of the steps towards proper nested virtualization support. There still remains a large amount of work onwards.
Indeed, no reboot required if those are the only patches that you are applying, as indicated in the blog post.
I just published, in the xcp-ng-testing repository, what is hopefully the very last round of fixes before the feature goes live.
You’ll have about three days to share your feedback if you’d like to be part of this final sprint 
.
Details at https://xcp-ng.org/forum/post/104961
This is, in theory, the very last round of fixes before QCOW2 support comes as an official update!
sm + blktap:
xapi:
blktap: 3.55.5-6.6.xcpng8.3 -> 3.55.5-6.7.xcpng8.3sm: 3.2.12-17.6.xcpng8.3 -> 3.2.12-17.7.xcpng8.3xapi: 26.1.3-1.9.xcpng8.3 -> 26.1.3-1.10.xcpng8.3If you are using XOSTOR, please refer to our documentation for the update method.
yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot
The usual update rules apply: pool coordinator first, etc.
Anything related to storage, be it with VHD or QCOW2 disks.
~3 days
@pkgw Our initial theory is that you might have applied updates at some point which had replaced the sm package with one that didn't support qcow2. Then a next update would have brought it back, but the metadata lost.
@pkgw Would it be possible to open a ticket and a support tunnel so that @Team-Storage can look at it?
@stormi Updated 2 pools @office but on both RPU failed after updating master and emptying secondary host. Had to install patches manually and then move VM's back......
Have you kept the logs?
Fixes for the top 3 issues are included in today's batch of updates for XCP-ng 8.3.
https://xcp-ng.org/blog/2026/04/28/april-2026-security-and-maintenance-updates-for-xcp-ng-8-3-lts/
We just published most of the updates tested above, plus embargoed security fixes:
https://xcp-ng.org/blog/2026/04/28/april-2026-security-and-maintenance-updates-for-xcp-ng-8-3-lts/
The release of the QCOW2 image format feature (packages sm, sm-fairlock and blktap) is planned in the coming days. You can still update a system which has these test packages with the security updates published today.
Thanks everyone for the tests!
@hoerup Where did you find out about this site?
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.