CVE-2026-99999 — PwnEscape : détection et atténuation

Guide pratique en espagnol pour savoir si un serveur Linux est exposé à CVE-2026-99999 (« PwnEscape ») et comment l'atténuer. Inclut un script qui inspecte la machine et rend un verdict avec la raison.

📋 Résumé

Champ	Valeur
CVE	CVE-2026-99999
Nom	PwnEscape
Composant	Noyau Linux, traitement des checksums IPv4 (`skb_checksum_help()`)
Gravité	CVSS 3.1 9.3 (Critique) — `AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`
Impact	Une VM malveillante peut lire la mémoire de l'hôte, le faire tomber et, en laboratoire, en prendre le contrôle avec root
Vecteur	Local : l'attaquant doit exécuter du code à l'intérieur d'une VM
Découvert par	Paulos Yibelo (pwn.ai), lors du Sandbox Challenge de Vercel
Publié le	15 octobre 2026
Correctif upstream	Commit `6785011f8b16` (Michael S. Tsirkin, Red Hat)
Exploitation active	Non signalée · Absent du catalogue KEV de la CISA

🧠 Qu'est-ce que c'est ? (expliqué simplement)

Pensez à un immeuble d'appartements :

L'immeuble est le serveur physique, l'hôte.
Chaque appartement est une machine virtuelle (VM).
PwnEscape est un défaut dans les murs de l'immeuble : depuis un appartement, un locataire malveillant peut espionner ou s'introduire dans l'administration de l'immeuble.

┌──────────────────────────────────────┐
│  HOST (servidor físico + hipervisor) │  ← aquí está la falla
│  Linux con KVM / QEMU / Firecracker  │
│                                      │
│   ┌─────────┐ ┌─────────┐ ┌────────┐ │
│   │  VM  A  │ │  VM  B  │ │  VM  C │ │
│   │         │ │(atacante)│ │        │ │
│   └─────────┘ └─────────┘ └────────┘ │
└──────────────────────────────────────┘

La faille se situe dans l'hôte, pas dans les VMs. C'est pourquoi :

✅ Si votre serveur est un VPS ou une VM (DigitalOcean, AWS, Hetzner, Proxmox, etc.), vous n'êtes pas la cible. C'est votre fournisseur ou l'administrateur de l'hôte qui doit corriger.
⚠️ Si votre serveur héberge des VMs (Proxmox, KVM/libvirt, OpenStack, Firecracker), vous êtes bien la cible, surtout si vous exécutez des VMs de tiers ou du code non fiable.

🔬 Comment ça fonctionne ? (niveau technique)

Linux permet aux paquets réseau de porter des métadonnées qui indiquent où commence un checksum et où son résultat est écrit. C'est une optimisation légitime pour le checksum offloading.

Le problème réside dans l'ordre des opérations :

Le noyau reçoit un paquet de la VM avec un header IPv4 normal (IHL = 20 octets) et le valide.
Ensuite, une opération de checksum différée, contrôlée par les métadonnées envoyées par la VM, réécrit ce même header déjà validé et le fait passer à IHL = 60 octets.
La logique de fragmentation fait confiance à la nouvelle valeur et copie plus de données que le paquet n'en contient réellement.
Ces octets supplémentaires sont de la mémoire de l'hôte (32 octets par paquet dans le test), et l'attaque peut être répétée.

Le correctif valide que le début du checksum ne peut pas pointer à l'intérieur d'un header IPv4 déjà traité. Il est appliqué sur cinq chemins réseau affectés.

Le code vulnérable existe depuis le noyau 2.6.27 (2008).

📦 Versions corrigées

Branche	Première version corrigée
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 et Proxmox utilisent leur propre numérotation (par exemple 5.15.0-125-generic ou 5.14.0-503.el9). Sur ces distributions, le numéro de version ne dit rien à lui seul : il faut consulter l'avis de sécurité de la distribution ou le changelog du noyau.

Les branches hors de cette liste (6.8, 6.19, 7.0, 7.1…) ne bénéficient plus du support upstream et n'ont pas reçu le correctif.

🔍 Suis-je affecté ?

Option A — Script automatique (recommandé)

curl -O https://raw.githubusercontent.com/alvaroguzmancode/CVE-2026-99999/refs/heads/main/check-pwnescape.sh
sudo bash check-pwnescape.sh

Le script vérifie trois choses :

Rôle de la machine : s'il s'agit d'une VM, si elle héberge des VM ou si elle peut les héberger mais ne le fait pas aujourd'hui.
Correctif : recherche le CVE dans le changelog du noyau et compare avec les versions corrigées.
Redémarrage en attente : s'il y a un nouveau noyau installé qui n'est pas encore actif.

Exemple de sortie sur 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.

Code de sortie	Signification
`0`	Non vulnérable ou non exposé
`1`	Vulnérable
`2`	Impossible de confirmer, à vérifier manuellement

Option B — Vérification manuelle

1. Suis-je une VM ou un hôte ?

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. Mon noyau est-il 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. Un redémarrage est-il nécessaire ?

[ -f /var/run/reboot-required ] && echo "Falta reiniciar"   # Debian / Ubuntu
needs-restarting -r                                          # RHEL

🛡️ Atténuation

1. Mettre à jour le noyau de l'hôte (solution réelle)

# Debian / Ubuntu / Proxmox
sudo apt update && sudo apt full-upgrade

# RHEL / Rocky / Alma / Fedora
sudo dnf update kernel

Les mainteneurs du noyau recommandent d'installer la version stable complète de votre distribution, et non d'appliquer le commit isolé.

2. Redémarrer et vérifier

sudo reboot
# después:
uname -r
sudo bash check-pwnescape.sh

Installer le paquet ne suffit pas : le nouveau noyau n’entre en vigueur qu’après un redémarrage. Dans les clusters, vérifiez chaque hyperviseur.

3. Corriger uniquement les VMs ne sert à rien

Mettre à jour le noyau à l’intérieur des VMs n’élimine pas le risque, car la faille se trouve sur l’hôte. Si vous êtes client d’un VPS, confirmez auprès de votre fournisseur qu’il a déjà corrigé ses hôtes.

4. Décharger KVM si vous ne l’utilisez pas

Si la machine a KVM chargé mais n’héberge pas de VMs, vous pouvez réduire la surface :

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

CVE-2026-99999

Populaires