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.
