Quick update now that Vates has published their official advisory.

First, kudos to the Vates security team for the thorough and timely response. VSA-2026-014 is well-documented and covers the full picture, including a third CVE I had not covered in my earlier posts.

VSA-2026-014 confirms what I outlined above: XCP-ng is affected by CVE-2026-43284 (XFRM-ESP) and is NOT affected by CVE-2026-43500 (no RxRPC support). The CVE I had missed: CVE-2026-46300 ("Fragnesia") also affects XCP-ng via the XFRM ESP-in-TCP subsystem. The same esp4/esp6 blacklist mitigation applies, with the same caveat @semarie raised: it will break encrypted private networks on XCP-ng.

Now that the VSA and official mitigation guidance are public, I'm releasing the diagnostic script I built. It's Python 3.6, no external dependencies, safe to run on production dom0. It tests whether an unprivileged process can engage the esp4 engine via the XFRM interface inside a user namespace — without touching any exploit code. Since both CVE-2026-43284 and CVE-2026-46300 (Fragnesia) require esp4 or esp6 to be reachable from an unprivileged namespace, and share the same mitigation, a positive result confirms exposure to both. Blacklist esp4/esp6, then run the script again — ACCESS DENIED means both CVEs are mitigated.

One important note before running it: please read the code before executing it on any of your systems. This is good practice with any script from the internet, regardless of the source. The code is intentionally short and straightforward so you can review it quickly and satisfy yourself that it does exactly what it says.

VSA-2026-014: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-014/
Diagnostic tool: https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester

A kernel patch from Vates is in progress. Apply as soon as it lands.

Just a quick update for anyone following this thread—I decided to test this out on my end to verify the impact.

After installing gcc in Dom0 and making a few necessary tweaks to the PoC code, I was able to successfully compile and run it. I managed to gain root access starting from a standard, unprivileged account. Based on this, I can confirm that a fully patched XCP-ng 8.3 system is indeed vulnerable to this attack.

However, I want to strongly emphasize a key point about the threat model here so we keep the risk in perspective: this is strictly a Local Privilege Escalation (LPE) vulnerability. An attacker cannot just trigger this remotely. To exploit this, someone absolutely must already have a provisioned account with access to your Dom0. If you are following best practices and strictly controlling who (and what) has shell access to Dom0, your immediate, real-world risk is significantly mitigated.

Hopefully, this helps clarify the exposure for everyone while we wait for an official patch upstream.

@LucienLassalle — Thanks Lucien, appreciate the detailed reply. Glad we landed on the same result independently, and the CI/testing rationale makes complete sense — stability matters more than rushing a same-day patch.

Good to see June Updates #1 out covering Fragnesia, ptrace_may_dream, and Pintheft, and good to know CIFSwitch will likely be treated the same way. I'll keep checking the blog and the VSA registry.

And noted on security@ for future reports. Thanks for the great work as always.

Just a quick update for anyone following this thread—I decided to test this out on my end to verify the impact.

After installing gcc in Dom0 and making a few necessary tweaks to the PoC code, I was able to successfully compile and run it. I managed to gain root access starting from a standard, unprivileged account. Based on this, I can confirm that a fully patched XCP-ng 8.3 system is indeed vulnerable to this attack.

However, I want to strongly emphasize a key point about the threat model here so we keep the risk in perspective: this is strictly a Local Privilege Escalation (LPE) vulnerability. An attacker cannot just trigger this remotely. To exploit this, someone absolutely must already have a provisioned account with access to your Dom0. If you are following best practices and strictly controlling who (and what) has shell access to Dom0, your immediate, real-world risk is significantly mitigated.

Hopefully, this helps clarify the exposure for everyone while we wait for an official patch upstream.

Hi all,

Flagging CIFSwitch (CVE-2026-46243, assigned June 1) for this community, since it touches dom0 directly. It's the fourth Linux LPE in the recent run after CopyFail, Dirty Frag, and Fragnesia. It spans the kernel's CIFS/SMB client and the cifs-utils userspace helper: an unprivileged local user forges a cifs.spnego key request, the kernel launches cifs.upcall as root, and the helper trusts attacker-controlled fields, switches into the attacker's namespace, and loads a malicious NSS library before dropping privileges — landing a root shell. Latent since 2007, public PoC available.

It's explicitly "non-universal" — the researcher (Asim Manizada) lists five conditions that must all hold. I went through them on a stock 8.3 host, and all five are met:

1. cifs-utils installed (affected version):

[root@xcpng ~]# rpm -q cifs-utils
cifs-utils-7.1-2.1.x86_64

2. CIFS module loadable:

[root@xcpng ~]# modinfo cifs | head -1
filename:  /lib/modules/4.19.0+1/kernel/fs/cifs/cifs.ko

3. Unprivileged user namespaces enabled:

[root@xcpng ~]# sysctl user.max_user_namespaces
user.max_user_namespaces = 9896

4. Default cifs.spnego request-key rule present (the trigger):

[root@xcpng ~]# cat /etc/request-key.d/cifs.spnego.conf
create  cifs.spnego    * * /usr/sbin/cifs.upcall %k

5. No LSM in the way — SELinux disabled by default on dom0:

[root@xcpng ~]# getenforce
Disabled

On several newer EL distros a default-enforcing SELinux policy blocks the chain even with cifs-utils present. dom0 ships with SELinux disabled, so that backstop isn't there for us.
The open question — and the reason I'm posting: all five userspace/config preconditions are met, but that doesn't by itself prove the kernel is exploitable. The deciding factor is whether the upstream fix (commit 3da1fdf, "smb: client: reject userspace cifs.spnego descriptions") has been backported into the current dom0 kernel (4.19.19-8.0.46.2.xcpng8.3). The most recent kernel update (May 2026 Updates #3, May 21) predates the CIFSwitch disclosure on May 28, so I'd assume it hasn't landed yet — but I can't confirm that from the changelog alone.

So, two things:

Has anyone at VATES already tested dom0 against this? A quick yes/no on whether a fully-patched 8.3 host is exploitable would settle it for the whole community, and would tell us whether a kernel update is in the pipeline.
If not, I'll take a crack at it. If I get time today I'll try to stand up the PoC (github.com/manizada/CIFSwitch) against a fully-patched, throwaway 8.3 test host — never anything production — and report back what I find. If someone's already done this, say the word and I won't duplicate the effort.

Context / mitigating factor: this is a local privesc, and a properly locked-down dom0 shouldn't have untrusted shell users to begin with — dom0 is meant to be a black box. So not drop-everything urgent. But it's unnecessary attack surface in the most privileged domain on the host, and a clean pivot after any partial compromise. Cheap to close.

Check your own dom0 (full five-condition sweep):

bashrpm -q cifs-utils
modinfo cifs 2>/dev/null | head -1
sysctl user.max_user_namespaces
cat /etc/request-key.d/cifs.spnego.conf
getenforce

Interim mitigation if you don't mount CIFS/SMB in dom0 (almost certainly the case — SRs use NFS/iSCSI/local):

yum remove cifs-utils

No reboot, no toolstack restart. Or blacklist the module:

echo "blacklist cifs" > /etc/modprobe.d/blacklist-cifs.conf

If you genuinely use CIFS in dom0, override the request-key rule to negate unsolicited requests instead.

Cheers

@Greg_E Would you know the version of the installed xen tools?

Quick update now that Vates has published their official advisory.

First, kudos to the Vates security team for the thorough and timely response. VSA-2026-014 is well-documented and covers the full picture, including a third CVE I had not covered in my earlier posts.

VSA-2026-014 confirms what I outlined above: XCP-ng is affected by CVE-2026-43284 (XFRM-ESP) and is NOT affected by CVE-2026-43500 (no RxRPC support). The CVE I had missed: CVE-2026-46300 ("Fragnesia") also affects XCP-ng via the XFRM ESP-in-TCP subsystem. The same esp4/esp6 blacklist mitigation applies, with the same caveat @semarie raised: it will break encrypted private networks on XCP-ng.

Now that the VSA and official mitigation guidance are public, I'm releasing the diagnostic script I built. It's Python 3.6, no external dependencies, safe to run on production dom0. It tests whether an unprivileged process can engage the esp4 engine via the XFRM interface inside a user namespace — without touching any exploit code. Since both CVE-2026-43284 and CVE-2026-46300 (Fragnesia) require esp4 or esp6 to be reachable from an unprivileged namespace, and share the same mitigation, a positive result confirms exposure to both. Blacklist esp4/esp6, then run the script again — ACCESS DENIED means both CVEs are mitigated.

One important note before running it: please read the code before executing it on any of your systems. This is good practice with any script from the internet, regardless of the source. The code is intentionally short and straightforward so you can review it quickly and satisfy yourself that it does exactly what it says.

VSA-2026-014: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-014/
Diagnostic tool: https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester

A kernel patch from Vates is in progress. Apply as soon as it lands.

I want to correct something I said in my earlier post, now that I've done a deeper analysis of the exploit chain.

I described the RxRPC component as being responsible for heap memory grooming, and suggested that without it a sophisticated attacker would need to find an alternative grooming technique. That framing was inaccurate, and I don't want it to create false reassurance in the community.

Here is what's actually going on:

RxRPC (CVE-2026-43500) was not added to the exploit chain to groom memory. It was added specifically to bypass Ubuntu's AppArmor policy, which blocks unprivileged user namespace creation by default. On Ubuntu, the ESP4 path requires unshare() to create a user namespace, and AppArmor prevents that — so the RxRPC path provides an alternative write primitive that doesn't need a namespace at all.

XCP-ng dom0 has no AppArmor. It is built on a CentOS 7 base where unprivileged user namespace creation is permitted by default. This means the ESP4 path (CVE-2026-43284) works directly, without any namespace restriction to bypass and without needing RxRPC at all.

The practical consequence: every supported XCP-ng installation (8.1, 8.2, 8.3) is fully exploitable via CVE-2026-43284 alone. The absence of rxrpc.ko does not provide protection on this platform. The older OS base actually makes the ESP4 path more straightforward to reach, not less.

I'm holding off publishing my diagnostic tool to give the VATES team time to finalise their VSA and patches for XCP-ng. In the meantime, the interim mitigation stands as I described — with @semarie's important caveat: blacklisting esp4/esp6 will break IPsec and the SDN controller's encrypted private tunnels. Check your environment before applying it.

And as I noted in my follow-up: this remains an LPE. If you have no unprivileged service accounts on dom0 (no Terraform, no monitoring agents, no central logging), your exposure is already limited. Audit what has shell access to dom0 and remove anything that doesn't strictly need it.

@semarie Thank you for the heads up.

@rvreugde I should add an important caveat. Because this is a Local Privilege Escalation (LPE) vulnerability, it requires local access to execute. If you haven't provisioned any unprivileged accounts in Dom0, your exposure is minimal, as an attacker would already need an existing foothold in the host OS to leverage these exploits.

As a side note, I just checked the active XCP-ng repositories for Dom0, and I don't see any official updates or patches pushed out for either vulnerability just yet.

@rvreugde As @bleader mentioned, VATES has documented the CopyFail security issue and released a patch. I've put together a lightweight Python script here to help you quickly check if your XCP-ng 8.3 host is vulnerable. If it is, you just need to run yum update and reboot the host (make sure to migrate or shut down your VMs first).

The Dirty Frag vulnerability is a bit more complex. The proof-of-concept (PoC) C code created by Hyunwoo Kim relies on a combination of factors: first, it uses heap memory grooming (manipulating the Linux kernel's protected memory), and then it leverages the esp4/esp6 modules to exploit that memory. This allows an unprivileged OS account to gain root privileges.

Fortunately, XCP-ng does not distribute the RxRPC code that Kim's specific PoC needs to groom the memory. However, the esp4 and esp6 modules are distributed with XCP-ng 8.3 as kernel modules that load on demand. Because of this, a sophisticated attacker could theoretically find an alternative way to groom the kernel memory, force the ESP modules to load, and achieve the same local privilege escalation.

As a potential mitigation, you could blacklist the esp4 and esp6 kernel modules, though I haven't yet investigated what side effects that might cause in an XCP-ng environment.

Hope this helps clarify things!

@bleader Do you know if VATES is now shipping those fixes in the XCP-ng Dom0 Repos?