XCP-ng Dirty Frag Diagnostic — CVE-2026-43284

A community diagnostic tool to determine whether an XCP-ng dom0 host is exposed to CVE-2026-43284 ("Dirty Frag"), a local privilege escalation vulnerability in the Linux kernel's xfrm-ESP subsystem.

TL;DR — All current XCP-ng releases (8.1, 8.2, 8.3) running the stock 4.19 dom0 kernel are in the vulnerable code range. No official XCP-ng patch has been published as of May 2026. This tool tells you definitively whether your host is exposed and provides a safe interim mitigation.

Background

"Dirty Frag" is a local privilege escalation vulnerability publicly disclosed in May 2026 by researcher Hyunwoo Kim (@v4bel). It exploits an in-place decryption fast path in the Linux kernel's IPsec ESP subsystem, introduced in January 2017 (kernel 4.14+). A working public proof-of-concept yields a root shell via standard syscalls with no kernel exploits required.

Two CVEs were published:

XCP-ng does not require CVE-2026-43500 to be exploitable. The esp4 path (CVE-2026-43284) alone is sufficient because XCP-ng dom0 has no AppArmor policy and allows unprivileged user namespace creation — the only precondition the esp4 exploit path requires. See TECHNICAL.md for the full analysis.

What This Tool Does

The diagnostic script tests the necessary and sufficient precondition for CVE-2026-43284 on XCP-ng: whether an unprivileged process can engage the esp4 in-place decryption engine via the XFRM netlink interface inside a user namespace.

It does not:

• Attempt privilege escalation
• Write any exploit payload
• Modify any system files
• Leave permanent artifacts (XFRM state is cleaned up on exit)

It is safe to run on production dom0.

Quick Start

# Clone the repository
git clone https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester.git
cd XCP_ng_CVE-2026-43284_tester

# Run the diagnostic (as non-root for the strongest proof)
python3 XCP_ng_CVE_2026_43284_tester.py

Note: Run as a non-root user where possible. This simulates the real threat model: a compromised service account or a guest escape reaching dom0. Running as root still produces a valid result but is less illustrative.

Expected Output — Vulnerable Host

=================================================================
  XCP-ng Dirty Frag Diagnostic -- CVE-2026-43284
  xfrm-ESP Page-Cache Write / Local Privilege Escalation
=================================================================
  Kernel  : 4.19.0+1
  Host    : xcpng-prod-01
  PID     : 52306  |  UID: 1000
=================================================================

[Phase 0] Pre-flight environment checks
---------------------------------------------
[*] Unprivileged user namespaces : ALLOWED
[*] esp4 blacklist in modprobe.d  : NOT FOUND
[*] CVE-2026-43284 patch in kernel RPM : NOT FOUND

[Phase 1] Baseline esp4 module state
---------------------------------------------
[*] esp4 is DORMANT -- not currently loaded in the kernel.
    The autoload mechanism may fetch it on demand via XFRM.

[Phase 2] Attempting esp4 engagement from unprivileged namespace
---------------------------------------------
[*] Spawning child in isolated user+network namespace
    (unshare -U -n -r) -- simulating a non-root local attacker

[*] Child signal    : XFRM SA accepted by kernel
[*] esp4 refcount   : 0 (before)  ->  1 (now)
[*] /proc/modules   : esp4 16384 1 - Live 0xffffffffc0a12000

[Phase 3] Engineering verdict
=================================================================

  [!!!]  PROOF OF EXPOSURE -- CVE-2026-43284  [!!!]

  esp4 refcount increased: 0 -> 1

  An unprivileged process inside a user+network namespace
  successfully registered an XFRM Security Association and
  engaged the esp4 in-place decryption engine in the host
  kernel. This is the gate condition for CVE-2026-43284.

  XCP-ng-specific analysis:
    [FAIL] Kernel 4.19 carries the vulnerable code (since 4.14)
    [FAIL] User namespaces are open -- esp4 path is reachable
    [OK]   rxrpc.ko absent -- CVE-2026-43500 does not apply
    [FAIL] esp4 path alone is sufficient on this configuration

Expected Output — Mitigated Host

[Phase 0] Pre-flight environment checks
---------------------------------------------
[+] esp4 blacklist found in /etc/modprobe.d/
    Module-load mitigation appears to be in place.
...
[Phase 2] Attempting esp4 engagement from unprivileged namespace
---------------------------------------------
[+] XFRM state add was REJECTED by the kernel.
    The esp4 engine was not engaged from the namespace.

[RESULT] The namespace loophole did NOT grant esp4 access.

Mitigation

Automated (recommended)

The included mitigate.sh script safely applies the mitigation, with built-in IPsec detection to prevent breaking tunnels:

# Check current status only (no changes)
sudo ./mitigate.sh --check

# Apply mitigation (aborts if IPsec is detected)
sudo ./mitigate.sh

# Remove mitigation (after applying official kernel patch)
sudo ./mitigate.sh --undo

Manual

Option A — Hosts NOT using IPsec (most dom0s):

echo 'install esp4 /bin/false' > /etc/modprobe.d/dirtyfrag-cve-2026-43284.conf
rmmod esp4 2>/dev/null || true
echo 3 > /proc/sys/vm/drop_caches

Option B — Hosts using IPsec (strongSwan / Libreswan):

Do NOT blacklist esp4 — it will immediately break all tunnels. Instead:

• Limit dom0 shell access to the minimum set of trusted administrator accounts
• Monitor the XCP-ng update announcements for the official kernel patch

⚠️ This is a LOCAL privilege escalation. An attacker must already have a shell or code execution on dom0. The primary defence is limiting who has local access to dom0 in the first place. Dom0 root = hypervisor root = all guest VMs compromised.

Requirements

No external Python libraries required. No pip install needed.

Files

XCP_ng_CVE-2026-43284_tester/
├── XCP_ng_CVE_2026_43284_tester.py   # Diagnostic script — run this first
├── mitigate.sh                        # Mitigation script with IPsec detection
├── README.md                          # This file — quick start and overview
├── TECHNICAL.md                       # Deep technical analysis — attack chain,
│                                      # why rxrpc is not needed on XCP-ng,
│                                      # script internals explained
├── CHANGELOG.md                       # Version history
└── LICENSE                            # MIT

Technical Details

For a complete explanation of:

• How Dirty Frag works mechanically (the page-cache write primitive)
• Why CVE-2026-43500 (RxRPC) is irrelevant to XCP-ng despite completing the chain on Ubuntu
• The full 6-step attack chain specific to XCP-ng dom0
• How every section of the diagnostic script works

See TECHNICAL.md.

Patch Status

Monitor: https://xcp-ng.org/forum/topic/365/updates-announcements

Responsible Disclosure Note

This tool tests only the precondition for exploitation (namespace + esp4 access). It does not contain, reproduce, or reference any exploit code. The underlying vulnerability is publicly known, has a published proof-of-concept by the original researcher, and has been assigned CVEs. The purpose of this tool is to help XCP-ng administrators determine their exposure and apply interim mitigations while awaiting an official kernel patch from Vates.

References

• CVE-2026-43284 — NVD
• Original write-up — Hyunwoo Kim (@v4bel)
• Microsoft Security Blog — Active attack advisory
• Sysdig — Detection guidance
• XCP-ng update announcements
• Kernel fix commit (upstream)

Author

Rodrigo Gracia — Community security contribution
XCP-ng / Xen Orchestra practitioner
https://github.com/grabesec
May 2026