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

Uno strumento diagnostico della community per determinare se un host XCP-ng dom0 è esposto a CVE-2026-43284 ("Dirty Frag"), una vulnerabilità di escalation dei privilegi locali nel sottosistema xfrm-ESP del kernel Linux.

TL;DR — Tutte le versioni attuali di XCP-ng (8.1, 8.2, 8.3) con il kernel dom0 4.19 di serie rientrano nella fascia di codice vulnerabile. Nessuna patch ufficiale XCP-ng è stata pubblicata ad oggi (maggio 2026). Questo strumento ti dice in modo definitivo se il tuo host è esposto e fornisce una mitigazione provvisoria sicura.

Contesto

"Dirty Frag" è una vulnerabilità di escalation dei privilegi locali resa pubblica a maggio 2026 dal ricercatore Hyunwoo Kim (@v4bel). Sfrutta un percorso rapido di decrittazione in-place nel sottosistema IPsec ESP del kernel Linux, introdotto a gennaio 2017 (kernel 4.14+). Un proof-of-concept pubblico funzionante consente di ottenere una shell di root tramite syscall standard, senza richiedere exploit del kernel.

Sono state pubblicate due CVE:

XCP-ng non richiede che CVE-2026-43500 sia sfruttabile. Il solo percorso esp4 (CVE-2026-43284) è sufficiente perché XCP-ng dom0 non ha alcuna policy AppArmor e consente la creazione di user namespace non privilegiati — l'unica precondizione richiesta dal percorso di sfruttamento esp4. Consulta TECHNICAL.md per l'analisi completa.

Cosa Fa Questo Strumento

Lo script diagnostico verifica la precondizione necessaria e sufficiente per CVE-2026-43284 su XCP-ng: se un processo non privilegiato può attivare il motore di decrittazione in-place esp4 tramite l'interfaccia netlink XFRM all'interno di uno user namespace.

Lo strumento non:

• tenta l'escalation dei privilegi
• scrive payload di exploit
• modifica file di sistema
• lascia artefatti permanenti (lo stato XFRM viene ripulito all'uscita)

È sicuro da eseguire su dom0 in produzione.

Avvio Rapido

# 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

Nota: esegui come utente non-root quando possibile. Questo simula il modello di minaccia reale: un account di servizio compromesso o una fuga dalla guest che raggiunge dom0. L'esecuzione come root produce comunque un risultato valido, ma è meno indicativa.

Output Atteso — Host Vulnerabile

=================================================================
  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

Output Atteso — Host Mitigato

[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.

Mitigazione

Automatica (consigliata)

Lo script mitigate.sh incluso applica la mitigazione in sicurezza, con rilevamento IPsec integrato per evitare di interrompere i tunnel:

# 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

Manuale

Opzione A — Host che NON usano IPsec (la maggior parte dei dom0):

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

Opzione B — Host che usano IPsec (strongSwan / Libreswan):

NON mettere in blacklist esp4 — interromperebbe immediatamente tutti i tunnel. In alternativa:

• Limita l'accesso shell a dom0 all'insieme minimo di account amministratore di fiducia
• Monitora gli annunci di aggiornamento XCP-ng per la patch ufficiale del kernel

⚠️ Questa è un'escalation dei privilegi LOCALE. Un attaccante deve già disporre di una shell o dell'esecuzione di codice su dom0. La difesa principale consiste nel limitare fin dall'inizio chi ha accesso locale a dom0. Root su dom0 = root sull'hypervisor = tutte le VM guest compromesse.

Requisiti

Nessuna libreria Python esterna richiesta. Nessuna installazione pip necessaria.

File

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

Dettagli Tecnici

Per una spiegazione completa di:

• Come funziona meccanicamente Dirty Frag (la primitiva di scrittura della page cache)
• Perché CVE-2026-43500 (RxRPC) è irrilevante per XCP-ng, nonostante completi la catena su Ubuntu
• L'intera catena d'attacco in 6 passaggi specifica per XCP-ng dom0
• Come funziona ogni sezione dello script diagnostico

Consulta TECHNICAL.md.

Stato della Patch

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

Nota sulla Divulgazione Responsabile

Questo strumento verifica solo la precondizione per lo sfruttamento (namespace + accesso a esp4). Non contiene, riproduce né fa riferimento ad alcun codice di exploit. La vulnerabilità sottostante è pubblicamente nota, dispone di un proof-of-concept pubblicato dal ricercatore originale e le sono state assegnate delle CVE. Lo scopo di questo strumento è aiutare gli amministratori XCP-ng a determinare la propria esposizione e ad applicare mitigazioni provvisorie in attesa della patch ufficiale del kernel da parte di Vates.

Riferimenti

• CVE-2026-43284 — NVD
• Articolo originale — Hyunwoo Kim (@v4bel)
• Microsoft Security Blog — Avviso di attacco attivo
• Sysdig — Guida al rilevamento
• Annunci di aggiornamento XCP-ng
• Commit di correzione del kernel (upstream)

Autore

Rodrigo Gracia — Contributo di sicurezza della community
Utilizzatore di XCP-ng / Xen Orchestra
https://github.com/grabesec
Maggio 2026