CVE-2026-99999 PwnEscape : la faille critique d'évasion VM qui menace les serveurs Linux

Une vulnérabilité critique du noyau Linux, référencée CVE-2026-99999 et surnommée PwnEscape, permet à une machine virtuelle KVM de lire la RAM de l'hôte physique et d'y écrire. Classée CVSS 9.3 (critique, vecteur AV:L/AC:L/PR:N/UI:N/S:C), elle exploite un défaut dans le traitement des checksums IPv4 de la pile réseau virtio. Le scope "Changed" signifie qu'un processus à l'intérieur d'un serveur virtuel peut compromettre le système d'exploitation hôte, brisant l'isolation entre machines virtuelles. La faille existe dans le noyau Linux depuis la version 2.6.27 (2008), soit 18 ans. Le correctif upstream (commit 6785011f8b16) a été intégré au noyau principal le 14 octobre 2026. Proxmox a publié son patch dans le noyau 7.0.14-24-pve (advisory PSA-2026-00068-1) le 16 octobre 2026. Tout administrateur de serveur VPS Linux ou de serveur dédié utilisant KVM doit vérifier sa version de noyau et appliquer la mise à jour sans délai.

Sources : advisory Proxmox PSA-2026-00068-1, analyse technique Pwn AI (Paulos Yibelo).

CVE-2026-99999 : comprendre la faille PwnEscape

La vulnérabilité se situe dans le traitement des paquets réseau IPv4 au niveau du noyau du système d'exploitation hôte, plus précisément dans le fichier net/ipv4/ip_output.c. Lorsqu'un serveur virtuel envoie un paquet réseau via l'interface virtio, il fournit des métadonnées de checksum (CHECKSUM_PARTIAL) qui indiquent au noyau hôte où compléter le calcul du checksum. Ce mécanisme d'offload est conçu pour décharger le processeur hôte du calcul de checksum sur chaque paquet réseau transitant par la pile IPv4.

Le problème est un défaut de type TOCTOU (time-of-check/time-of-use) : le noyau hôte valide l'en-tête IPv4, mais la fonction skb_checksum_help() complète ensuite le checksum et réécrit le champ ihl (longueur d'en-tête). L'octet passe de 0x45 (en-tête de 20 octets) à 0x4f (en-tête de 60 octets). Le fragmenteur IPv4 (ip_do_fragment) utilise cette longueur modifiée et lit au-delà des limites logiques du paquet, exposant 32 octets de mémoire RAM de l'hôte par tentative.

Les chercheurs de Pwn AI, menés par Paulos Yibelo, ont découvert et signalé la faille. Ils ont démontré en laboratoire :

• Lecture mémoire : 32 octets de RAM hôte exposés par tentative, ce qui permet de cartographier progressivement la mémoire du noyau de la machine physique.
• Écriture contrôlée : des écritures sélectives de 64 octets dans la mémoire du noyau hôte en enchainant les mutations de checksum.
• Évasion complète : une chaine d'exploitation guest-to-host réalisée sur du hardware isolé, avec exécution de commandes root sur l'hôte depuis l'intérieur d'une VM.

Le correctif introduit une fonction de validation ip_check_csum_start() qui vérifie que la position checksum_start ne peut pas pointer à l'intérieur d'un en-tête IPv4 déjà analysé. La correction touche cinq sites de complétion de checksum répartis dans six fichiers du noyau.

Infrastructure concernée : du serveur privé virtuel au cluster de virtualisation

CVE-2026-99999 affecte toute infrastructure de virtualisation reposant sur KVM (Kernel-based Virtual Machine), l'hyperviseur intégré au noyau Linux. KVM est la technologie utilisée par Proxmox VE, par les plateformes cloud publiques basées sur Linux, et par la quasi-totalité des hébergeurs de serveurs VPS. Il isole les serveurs virtuels les uns des autres en s'appuyant sur le noyau hôte pour gérer le réseau (virtio-net), l'accès aux processeurs (vCPU), la RAM allouée à chaque VM et le stockage sur les disques SSD ou HDD du serveur physique.

PwnEscape compromet cette isolation. Un attaquant exécutant du code dans un serveur virtuel hébergé sur un hôte vulnérable peut lire la RAM d'autres machines virtuelles via la mémoire de l'hôte. Dans un cluster Proxmox configuré en haute disponibilité, où les VM peuvent migrer automatiquement d'un nœud à l'autre, chaque hôte du cluster doit être corrigé : une migration de VM vers un nœud non patché rétablit l'exposition.

Impact pour les administrateurs de VPS et serveurs dédiés

En pratique, voici ce que cette faille change selon votre situation :

• Hébergeurs et opérateurs Proxmox : un locataire malveillant disposant d'un serveur VPS peut accéder à la RAM de l'hôte physique, compromettant l'isolation entre les serveurs virtuels hébergés sur la même machine. Toutes les VM du nœud sont exposées : serveur web, bases de données, serveurs de jeu.
• Administrateurs de serveurs dédiés avec Proxmox : si vous hébergez plusieurs machines virtuelles sur un serveur dédié (serveurs de jeu, services web, backup), une VM compromise peut atteindre les autres via la mémoire de l'hôte. Cela concerne aussi les adresses IP privées de votre réseau interne, car l'attaque opère au niveau du noyau, en dessous de toute règle de firewall réseau.
• Serveurs VPS managés : si votre serveur privé virtuel est hébergé chez un prestataire, c'est à l'hébergeur de mettre à jour le noyau de l'hôte. Vous ne pouvez pas corriger la faille depuis l'intérieur de votre VPS. Vérifiez auprès de votre fournisseur que le correctif a été déployé sur le hardware hôte.

Le vecteur d'attaque est local (il faut exécuter du code dans la VM invitée), mais dans un contexte multi-locataire, chaque serveur VPS constitue un environnement potentiellement hostile pour l'hôte. C'est précisément le scénario de la virtualisation partagée : un serveur physique unique fait tourner des dizaines de serveurs virtuels de clients différents, partageant les processeurs, la RAM et la bande passante réseau.

Vérifier si votre serveur est vulnérable

La première étape consiste à identifier la version du noyau Linux en cours d'exécution sur votre serveur. Connectez-vous en SSH à votre VPS ou serveur dédié et exécutez :

uname -r

Le résultat affiche la version du noyau du système d'exploitation. Voici comment interpréter les cas courants :

Sur un hôte Proxmox, vérifiez précisément le paquet installé :

dpkg -l | grep proxmox-kernel

Si la version affichée est antérieure à 7.0.14-24-pve, votre serveur est vulnérable. Sur une distribution standard (Ubuntu, Debian, AlmaLinux), consultez les bulletins de sécurité de votre distribution pour confirmer que le correctif CVE-2026-99999 est disponible pour votre version de noyau.

Appliquer le correctif sur Proxmox VE

Proxmox a publié le noyau corrigé 7.0.14-24-pve dans ses dépôts officiels. Avant toute intervention, effectuez un backup de vos configurations et données critiques. Sauvegardez vos données avec rsync vers un serveur distant. Connectez-vous ensuite en SSH à l'hôte Proxmox (pas aux machines virtuelles) et exécutez :

apt update && apt full-upgrade -y

Vérifiez que le nouveau noyau est bien installé :

dpkg -l | grep proxmox-kernel | grep 7.0.14-24

Puis redémarrez l'hôte pour charger le noyau corrigé :

reboot

Après le redémarrage, confirmez avec uname -r que le noyau actif est bien 7.0.14-24-pve ou plus récent. Les serveurs virtuels hébergés sur cet hôte n'ont pas besoin d'être modifiés : c'est le noyau de l'hôte qui contenait la faille. Sur un cluster Proxmox, répétez l'opération sur chaque nœud. Planifiez ce redémarrage en dehors des heures de pointe, car il interrompt brièvement toutes les VM hébergées sur le nœud. Si votre cluster est configuré en haute disponibilité, les machines virtuelles migreront automatiquement vers un autre nœud pendant le redémarrage.

Appliquer le correctif sur un noyau upstream

Si votre hôte KVM utilise un noyau Linux standard (Ubuntu, Debian, AlmaLinux), le correctif correspond au commit upstream 6785011f8b16, intitulé "ipv4: validate checksum_start before completing checksum", écrit par Michael S. Tsirkin (Red Hat). Il a été fusionné dans net.git le 8 octobre 2026 et intégré au noyau principal le 14 octobre. Sept noyaux stables corrigés ont été publiés le 15 octobre 2026.

Sur Ubuntu ou Debian, mettez à jour le noyau via le gestionnaire de paquets :

sudo apt update && sudo apt upgrade -y linux-image-$(uname -r | sed 's/-[a-z].*//g')*

Après installation du nouveau noyau, un redémarrage est nécessaire pour que le système d'exploitation charge la version corrigée. Si votre distribution n'a pas encore publié de noyau intégrant le correctif, configurez les mises à jour de sécurité automatiques pour l'appliquer dès sa disponibilité.

Mitigation temporaire sans redémarrage

Si un redémarrage immédiat n'est pas possible (serveur de production à forte charge, hébergeant des services critiques), il existe une mitigation temporaire : désactiver l'offload de checksum sur les interfaces virtio-net. Cette opération réduit légèrement les performances réseau (le processeur hôte recalcule chaque checksum IPv4), mais bloque le vecteur d'attaque.

Pour un serveur virtuel lancé via QEMU/KVM en ligne de commande, ajoutez les options suivantes à la configuration de l'interface réseau :

-device virtio-net-pci,netdev=n0,csum=off,guest_csum=off

Sous libvirt (Proxmox, virt-manager), configurez l'interface réseau de la VM dans le fichier XML :

<interface type='bridge'>
  <driver>
    <host csum='off'/>
    <guest csum='off'/>
  </driver>
</interface>

Cette mitigation est un palliatif. Le correctif noyau reste la solution définitive : il corrige la validation sans impact sur les performances réseau ni sur la bande passante disponible pour vos serveurs virtuels.

Mesures complémentaires de sécurisation

Au-delà de ce correctif, cette faille rappelle l'importance d'une hygiène de sécurité rigoureuse sur les serveurs de virtualisation. Un serveur dédié ou un serveur VPS hébergeant des machines virtuelles doit être maintenu avec la même rigueur que n'importe quel serveur web exposé sur Internet :

• Mises à jour du noyau : appliquez les correctifs de sécurité dès leur publication. CVE-2026-99999 existait depuis 2008, soit 18 ans sans détection. Automatisez les mises à jour de sécurité sur vos serveurs Ubuntu pour ne pas dépendre d'une vérification manuelle.
• Firewall et filtrage réseau : configurez un pare-feu sur l'hôte de virtualisation pour limiter les flux réseau entre les machines virtuelles. Configurez nftables sur votre serveur Linux pour filtrer le trafic à l'entrée. Notez que le firewall ne bloque pas cette faille spécifique (qui opère au niveau du noyau, sous la pile réseau), mais il réduit la surface d'attaque globale.
• Accès SSH renforcé : sécurisez l'accès SSH à vos hôtes de virtualisation avec une authentification par clé et la désactivation du login root. L'accès SSH à l'hôte Proxmox est la porte d'entrée vers l'ensemble des serveurs virtuels hébergés.
• Backup avant intervention : avant tout redémarrage ou mise à jour de noyau, effectuez une sauvegarde (backup) des configurations et données critiques vers un serveur distant.
• Surveillance des ressources : surveillez les ressources de vos serveurs (charge processeur, consommation RAM, espace disque, bande passante réseau) pour détecter un comportement anormal : pic de charge CPU inexpliqué, processus inconnus, trafic réseau inhabituel sur les adresses IP de vos VM.
• Durcissement global : appliquez les premiers réglages de sécurisation d'un serveur dédié si ce n'est pas déjà fait.

Chronologie de la divulgation

Questions fréquentes sur CVE-2026-99999

Retrouvez ci-dessous les réponses aux questions les plus courantes des administrateurs de serveurs virtuels et de serveurs dédiés concernant cette faille.

Conclusion

CVE-2026-99999 (PwnEscape) est une faille critique du noyau Linux qui remet en cause l'isolation entre serveurs virtuels KVM sur un même hôte. Le correctif est disponible : noyau 7.0.14-24-pve pour Proxmox, commit 6785011f8b16 pour le noyau upstream, et sept noyaux stables corrigés pour les principales distributions. Si vous administrez un serveur VPS Linux ou un serveur dédié sous KVM, vérifiez votre version de noyau avec uname -r et appliquez la mise à jour. En attendant le redémarrage, la désactivation de l'offload de checksum sur les interfaces virtio-net offre une mitigation temporaire. Si votre serveur privé virtuel est hébergé chez un prestataire, contactez-le pour confirmer que le patch a été déployé sur l'infrastructure hôte.