Proxmox VE e la falla PwnEscape CVE-2026-99999: aggiornare al kernel 7.0.14-24

Articolo aggiornato al 21 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Proxmox rilascia nuove correzioni.

Se avete in gestione uno o più host Proxmox VE, questa settimana c’è un aggiornamento che non va lasciato in coda. Si chiama PwnEscape, è registrato come CVE-2026-99999 ed è una vulnerabilità del kernel Linux che permette a una macchina virtuale di uscire dal proprio isolamento e arrivare all’host. Il punteggio CVSS assegnato è 9.3, quindi critico.

Il difetto non sta in KVM in senso stretto ma nello stack di rete: il kernel dell’host non valida abbastanza i metadati del checksum che arrivano dalla scheda di rete virtuale virtio. Una VM può inviare pacchetti costruiti apposta che, quando l’host li frammenta, scrivono due byte dove non dovrebbero. Il risultato può essere la lettura di memoria dell’host, un crash o, nel caso peggiore, l’esecuzione di codice sull’host. Il bug è nel kernel dal 2008 ed è stato corretto upstream a metà ottobre.

La buona notizia è che Proxmox ha già pubblicato il kernel corretto con l’avviso PSA-2026-00068-1 del 16 ottobre. Ecco come verificare e aggiornare senza sorprese.

Chi è coinvolto

È esposto qualsiasi host Linux che fa girare VM KVM con schede di rete virtio, quindi praticamente tutte le installazioni Proxmox VE. Il rischio concreto dipende da chi controlla le VM: chi ha il pieno controllo del sistema operativo di una macchina virtuale può tentare l’attacco. Per una PMI il caso tipico non è il cliente ostile ma la VM compromessa: un server web esposto, un gestionale con una vulnerabilità, un RDS bucato. Oggi un attacco del genere resta confinato nella VM; con PwnEscape potrebbe arrivare all’hypervisor e da lì a tutte le altre macchine.

Al momento non risultano exploit pubblici, ma i dettagli tecnici sono stati pubblicati e io non aspetterei.

Attenzione: la correzione è disponibile solo per la serie di kernel 7.0.14, quella di Proxmox VE 9.2. Sul forum lo staff ha chiarito che le serie a fine vita, compreso il kernel 6.8 di Proxmox VE 8, non riceveranno più aggiornamenti. Se avete ancora host su PVE 8 o precedenti, questo è il momento di pianificare l’upgrade alla 9.

Prima di iniziare

Verificate che versione di kernel sta girando e quali sono installate:

uname -r
pveversion -v | grep -i kernel
proxmox-boot-tool kernel list

Il kernel corretto è proxmox-kernel-7.0.14-24-pve (o la variante -signed se usate Secure Boot), oppure uno successivo. Se uname -r mostra una versione precedente, l’host è vulnerabile anche se il pacchetto nuovo è già installato: il kernel diventa attivo solo dopo il riavvio.

Prima di toccare qualcosa:

• controllate che l’ultimo backup delle VM, su Proxmox Backup Server o con vzdump, sia andato a buon fine;
• guardate l’output di proxmox-boot-tool kernel list: se c’è un kernel “pinned”, dopo l’aggiornamento l’host continuerà ad avviarsi con quello;
• se usate moduli DKMS (driver NVIDIA, schede di rete particolari), tenete presente che sul forum c’è chi segnala la mancata compilazione del driver NVIDIA sul nuovo kernel;
• concordate una finestra di manutenzione: senza cluster, il riavvio dell’host ferma tutte le VM.

Aggiornare il kernel su Proxmox VE

1. Se l’host fa parte di un cluster, svuotatelo: migrate le VM su un altro nodo dall’interfaccia (Datacenter → nodo → Bulk Actions → Bulk Migrate) oppure, con HA attivo, mettete il nodo in manutenzione:

ha-manager crm-command node-maintenance enable PVE01

2. Aggiornate i pacchetti. Su Proxmox usate sempre full-upgrade, mai il semplice apt upgrade:

apt update
apt list --upgradable | grep proxmox-kernel
apt full-upgrade

3. Se il kernel 7.0.14-24 non compare, controllate il repository: secondo lo staff è arrivato prima su pve-no-subscription e poi su enterprise. Chi ha la sottoscrizione dovrebbe ormai trovarlo, ma verificate.
4. Se avevate un kernel bloccato, sbloccatelo con proxmox-boot-tool kernel unpin.
5. Riavviate l’host e, a riavvio completato, verificate:

uname -r
# deve restituire 7.0.14-24-pve o successivo

6. Togliete il nodo dalla manutenzione (ha-manager crm-command node-maintenance disable PVE01), riportate le VM e passate al nodo successivo, uno alla volta.

Io preferisco non fidarmi del solo “il pacchetto è installato”: l’unica prova che conta è uname -r dopo il riavvio, nodo per nodo.

Se il problema persiste

Se dopo il riavvio qualcosa non va (driver che non si carica, scheda di rete che non sale), potete tornare temporaneamente al kernel precedente senza disinstallare nulla:

proxmox-boot-tool kernel list
proxmox-boot-tool kernel pin 7.0.14-XX-pve --next-boot

Con --next-boot il blocco vale solo per il prossimo avvio, quindi il successivo riavvio torna al kernel corretto. Attenzione: con il kernel vecchio l’host torna vulnerabile, quindi usatelo solo per il tempo necessario a capire il problema.

C’è anche una segnalazione sul forum, non ancora confermata dallo staff, di un problema del 7.0.14-24 con le hugepages: con vm.hugetlb_optimize_vmemmap=1 la riduzione del pool a caldo farebbe perdere le pagine fino al riavvio. Chi usa le hugepages può evitare che Proxmox riduca il pool allo spegnimento delle VM con l’opzione keephugepages: 1 nella configurazione della VM.

Se non potete riavviare a breve, esistono mitigazioni che disattivano l’offload del checksum sulla scheda virtio delle singole VM, ma costano prestazioni, richiedono comunque il riavvio delle VM e su Proxmox non sono gestibili dall’interfaccia. Lo sconsiglio: la strada giusta resta il kernel aggiornato. Discorso a parte per gli host Linux con KVM o libvirt fuori da Proxmox: Debian ha già i kernel corretti per bookworm e trixie, mentre per Red Hat e Ubuntu, negli ultimi aggiornamenti dei giorni scorsi, la correzione non era ancora uscita: controllate gli avvisi della vostra distribuzione.

Vi è capitato qualche intoppo aggiornando i vostri host Proxmox al kernel 7.0.14-24? Raccontate nei commenti cosa avete trovato e come l’avete risolto: possono essere utili ad altri.