alvaroguzmancode/cve-2026-99999Guida in spagnolo e script Bash per verificare se un host Linux è esposto a CVE-2026-99999 (PwnEscape), un'evasione dal kernel VM-to-host, con verifica delle patch e passaggi di mitigazione.
Guida pratica in spagnolo per sapere se un server Linux è esposto a CVE-2026-99999 ("PwnEscape") e come mitigarla. Include uno script che controlla la macchina e fornisce un verdetto con la motivazione.
| Campo | Valore |
|---|---|
| CVE | CVE-2026-99999 |
| Nome | PwnEscape |
| Componente | Kernel Linux, elaborazione dei checksum IPv4 (skb_checksum_help()) |
| Gravità | CVSS 3.1 9.3 (Critica) — AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| Impatto | Una VM malevola può leggere la memoria dell'host, mandarlo in crash e, in laboratorio, prenderne il controllo con root |
| Vettore | Locale: l'attaccante deve eseguire codice all'interno di una VM |
| Scoperta da | Paulos Yibelo (pwn.ai), durante il Sandbox Challenge di Vercel |
| Pubblicato | 15 ottobre 2026 |
| Fix upstream | Commit 6785011f8b16 (Michael S. Tsirkin, Red Hat) |
| Sfruttamento attivo | Non segnalato · Non è nel catalogo KEV di CISA |
Pensa a un condominio:
┌──────────────────────────────────────┐
│ HOST (servidor físico + hipervisor) │ ← aquí está la falla
│ Linux con KVM / QEMU / Firecracker │
│ │
│ ┌─────────┐ ┌─────────┐ ┌────────┐ │
│ │ VM A │ │ VM B │ │ VM C │ │
│ │ │ │(atacante)│ │ │ │
│ └─────────┘ └─────────┘ └────────┘ │
└──────────────────────────────────────┘
La falla è nell'host, non nelle VM. Per questo:
Linux consente ai pacchetti di rete di trasportare metadati che indicano dove inizia un checksum e dove viene scritto il suo risultato. È un'ottimizzazione legittima per il checksum offloading.
Il problema è l'ordine delle operazioni:
La correzione verifica che l'inizio del checksum non possa puntare all'interno di un header IPv4 già elaborato. Viene applicata in cinque percorsi di rete interessati.
Il codice vulnerabile esiste dal kernel 2.6.27 (2008).
| Ramo | Prima versione corretta |
|---|---|
| 5.10 | 5.10.272 |
| 5.15 | 5.15.223 |
| 6.1 | 6.1.190 |
| 6.6 | 6.6.159 |
| 6.12 | 6.12.113 |
| 6.18 | 6.18.57 |
| 7.2 | 7.2.11 |
| Mainline | 7.3-rc7 |
⚠️ Ubuntu, RHEL/Rocky/Alma, SUSE e Proxmox usano una numerazione propria (ad esempio
5.15.0-125-generico5.14.0-503.el9). In queste distro la versione da sola non dice nulla: bisogna consultare l'avviso di sicurezza della distro o il changelog del kernel.I rami al di fuori di questo elenco (6.8, 6.19, 7.0, 7.1…) non hanno più supporto upstream e non hanno ricevuto la correzione.
curl -O https://raw.githubusercontent.com/alvaroguzmancode/CVE-2026-99999/refs/heads/main/check-pwnescape.sh
sudo bash check-pwnescape.sh
Lo script controlla tre cose:
Esempio di output su un VPS:
== VEREDICTO ==
Rol: Este equipo ES una máquina virtual; no hospeda otras VMs.
Kernel: VULNERABLE — la versión del kernel es anterior a la corregida.
NO EXPUESTO DIRECTAMENTE.
La falla solo se explota desde una VM hacia el servidor que la hospeda.
Este equipo no hospeda VMs, así que no hay a quién atacar desde aquí.
Ojo: el que SÍ debe estar parchado es el host que aloja esta VM
(tu proveedor de nube o tu servidor Proxmox/KVM). Confírmalo con ellos.
| Codice di uscita | Significato |
|---|---|
0 | Non vulnerabile o non esposto |
1 | Vulnerabile |
2 | Impossibile confermare, è necessario verificare manualmente |
1. Sono una VM o un host?
systemd-detect-virt # "kvm", "xen", etc. = eres una VM; "none" = físico
pgrep -a qemu-ga # si aparece, eres una VM (QEMU Guest Agent)
lsmod | grep -E 'kvm|vhost' # módulos de virtualización cargados
cat /sys/module/kvm_intel/refcnt 2>/dev/null || cat /sys/module/kvm_amd/refcnt # >0 = hay VMs usando KVM
virsh list --all 2>/dev/null # VMs de libvirt
pgrep -a '^(qemu-system|firecracker)' # VMs / microVMs corriendo
2. Il mio kernel ha la patch?
uname -r
# Debian / Ubuntu
zgrep -i "CVE-2026-99999" /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz
# RHEL / Rocky / Alma / Fedora
rpm -q --changelog kernel-core-$(uname -r) | grep -i "CVE-2026-99999"
3. Manca un riavvio?
[ -f /var/run/reboot-required ] && echo "Falta reiniciar" # Debian / Ubuntu
needs-restarting -r # RHEL
# Debian / Ubuntu / Proxmox
sudo apt update && sudo apt full-upgrade
# RHEL / Rocky / Alma / Fedora
sudo dnf update kernel
I manutentori del kernel consigliano di installare la versione stabile completa della tua distro, non di applicare il singolo commit.
sudo reboot
# después:
uname -r
sudo bash check-pwnescape.sh
L'installazione del pacchetto non basta: il nuovo kernel entra in uso solo dopo il riavvio. Nei cluster, verifica ogni hypervisor.
Aggiornare il kernel all'interno delle VM non elimina il rischio, perché il difetto è nell'host. Se sei cliente di un VPS, conferma con il tuo provider che abbia già applicato le patch ai propri host.
Se la macchina ha KVM caricato ma non ospita VM, puoi ridurre la superficie:
sudo modprobe -r kvm_intel kvm_amd kvm 2>/dev/null
echo -e "blacklist kvm_intel\nblacklist kvm_amd\nblacklist kvm" | sudo tee /etc/modprobe.d/no-kvm.conf
Queste misure non correggono la vulnerabilità, ma limitano ciò che otterrebbe un attaccante che riesca a uscire da una VM: