# PwnEscape : faille Linux/KVM, correctifs Proxmox et Debian > PwnEscape CVE-2026-99999 : risque d'évasion de VM vers l'hôte Linux, noyaux corrigés pour Proxmox et Debian, état Ubuntu et contrôles à réaliser. - URL canonique : [https://forgetaboutit.fr/blog/pwnescape-cve-2026-99999-linux-kvm-proxmox/](https://forgetaboutit.fr/blog/pwnescape-cve-2026-99999-linux-kvm-proxmox/) - Publication : 2026-10-19T07:45:00.000Z - Catégorie : Sécurité - Sujets : PwnEscape, CVE-2026-99999, Linux, KVM, Proxmox, Virtualisation, Patch management Dans le cadre de notre **veille sécurité**, nous signalons **PwnEscape**, suivie sous l'identifiant **CVE-2026-99999**. Cette faille du réseau du noyau Linux peut permettre à une machine virtuelle de franchir la frontière qui la sépare de son hôte. **La priorité est de corriger les hyperviseurs, pas seulement les systèmes installés dans les VM.** Des correctifs sont identifiés pour Proxmox et Debian. Cet article fait le point au **19 octobre 2026**, après la divulgation du 15 octobre et l'actualisation des informations de distribution pendant le week-end. Source : suivi technique VirtFusion, actualisé le 18 octobre. ## Ce que permet PwnEscape La recherche de pwn.ai décrit une fuite de mémoire de l'hôte et un plantage provoqués depuis une VM. Les chercheurs rapportent également une chaîne d'exploitation permettant d'exécuter du code avec les droits root sur leur propre hôte de laboratoire. Cette dernière démonstration ne constitue pas une preuve de prise de contrôle d'un fournisseur en production. Source : publication des chercheurs. Pour une infrastructure mutualisée, l'enjeu dépasse donc une seule machine virtuelle : la confidentialité de la mémoire et la disponibilité du serveur physique sont en cause. Le scénario documenté suppose un attaquant capable d'agir depuis l'intérieur d'une VM avec les privilèges nécessaires. Il ne s'agit pas d'une compromission déclenchable par n'importe quel visiteur depuis Internet. AWS décrit précisément cette exposition pour les environnements KVM et virtio-net autogérés. Source : bulletin AWS. ## Une faille réseau de l'hôte, pas seulement un problème de KVM Le défaut concerne le traitement des métadonnées de somme de contrôle des paquets. Des informations incorrectes peuvent conduire le noyau à modifier un en-tête IPv4 qu'il avait déjà interprété. Le correctif ajoute une validation avant la fin du calcul de checksum. Source : fiche Debian et référence du correctif Linux. Le chemin **virtio-net/TAP**, utilisé pour les échanges réseau de machines virtuelles, rend ce défaut accessible depuis un invité. **Désactiver la virtualisation imbriquée ne suffit pas à écarter le risque.** Le suivi VirtFusion couvre explicitement les deux configurations. Source : périmètre technique. C'est une différence importante avec [Januscape, la faille KVM/x86 que nous avions analysée](/blog/januscape-cve-2026-53359-kvm-x86-guest-to-host/) : deux alertes d'évasion de VM peuvent avoir des conditions d'exposition différentes. Il faut qualifier chaque vulnérabilité sur son propre périmètre. ## Versions corrigées : Proxmox, Debian et état Ubuntu Voici les informations vérifiées au **19 octobre 2026**. Les numéros Debian désignent les versions du paquet source `linux`, pas nécessairement la chaîne affichée par `uname -r`. | Environnement | Référence de correction | Action à prévoir | | --- | --- | --- | | Proxmox VE, série de noyaux 7.0.14 | `proxmox-kernel-7.0.14-24-pve`, variante signée comprise | Installer le noyau corrigé fourni par Proxmox et vérifier son chargement | | Debian 12 Bookworm | Paquet source `linux` à partir de `6.1.190-1` | Appliquer la mise à jour de sécurité correspondant à l'architecture de l'hôte | | Debian 13 Trixie | Paquet source `linux` à partir de `6.12.113-1` | Appliquer la mise à jour de sécurité correspondant à l'architecture de l'hôte | | Ubuntu 22.04 et 24.04 LTS, paquet `linux` | Statut « Needs evaluation » lors de la consultation | Suivre la fiche Canonical du paquet et de la branche réellement utilisés | Références : réponse de l'équipe Proxmox, suivi Debian et fiche Canonical. Le statut Ubuntu signifie que cette fiche ne fournit pas encore de verdict de correction pour ces entrées. Ce n'est ni une confirmation d'absence de risque ni une version corrective à installer. Sur Proxmox, **conservez les paquets et le parcours de mise à jour de la plateforme** : le seuil d'un paquet Debian ne remplace pas la vérification du noyau Proxmox. Contrôlez également sa disponibilité dans le dépôt configuré sur chaque nœud. ## Quels hôtes traiter en premier ? Notre recommandation est de commencer par les machines qui exécutent des invités dont le contenu ou les administrateurs ne sont pas entièrement maîtrisés : - plateformes de VPS et environnements multi-clients ; - VM de test, de formation ou de développement ouvertes à plusieurs équipes ; - environnements de build et sandboxes fondés sur des machines virtuelles ; - hôtes portant des VM exposées, susceptibles de fournir un premier accès après une compromission applicative. Pour chaque nœud, rapprochez l'inventaire des VM, le modèle réseau et la version du noyau. Un cluster ne doit pas être déclaré corrigé sur la seule base d'un nœud mis à jour. ## Vérifier les hyperviseurs sans lancer d'exploit Ces commandes de lecture sont à exécuter **sur l'hôte de virtualisation**. Elles servent à l'inventaire, pas à démontrer à elles seules l'absence de vulnérabilité. Relevez le noyau en cours d'exécution : ```bash uname -r ``` Sur Proxmox, relevez les versions de la plateforme et des paquets : ```bash pveversion -v ``` Sur Debian, Ubuntu ou Proxmox, listez les paquets noyau installés : ```bash dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' 'linux-image*' 'proxmox-kernel*' 'pve-kernel*' ``` Selon la machine, certains motifs ne correspondront à aucun paquet et seront signalés comme tels. Retenez les entrées installées, puis rapprochez-les du bulletin fournisseur. **Un noyau corrigé présent sur disque n'est pas forcément celui qui tourne.** Refaire ce contrôle après le redémarrage permet de repérer un ancien noyau toujours sélectionné au démarrage. Ne lancez pas de démonstration d'exploitation sur les hôtes métier. ## Corriger un cluster sans improviser la maintenance Nous recommandons de traiter l'alerte comme une opération sur l'infrastructure entière : 1. **Qualifier le parc** : hôtes, noyaux chargés, dépôts, VM et services critiques. 2. **Préparer l'intervention** : sauvegardes exploitables, accès console, capacité restante, quorum et état du stockage. 3. **Installer le noyau corrigé** par le mécanisme prévu pour la distribution ou la plateforme. 4. **Organiser le redémarrage** : déplacer les charges compatibles lorsque le cluster le permet ; prévoir une interruption pour les autres. 5. **Valider le retour en service** : noyau chargé, réseau des invités, stockage, applications et journaux. 6. **Poursuivre sur les autres nœuds**, puis conserver la trace des versions et contrôles réalisés. La haute disponibilité et les possibilités de migration aident à organiser cette séquence. Elles ne corrigent pas le noyau à la place de l'administrateur. Nous détaillons cette logique dans notre article sur les [correctifs Linux et la maintenance des clusters Proxmox](/blog/failles-kernel-linux-patcher-sans-interruption-proxmox-hyperconvergence/). Si vous utilisez du livepatch, faites confirmer la couverture de **cette CVE sur le noyau exact**. AWS ne propose pas de contournement pour le scénario décrit dans son bulletin : modifier quelques paramètres réseau ne doit pas être considéré comme un remplacement validé du correctif. Source : remédiation et absence de workaround dans l'avis AWS. ## Notre lecture opérationnelle PwnEscape rappelle que l'isolation des VM dépend aussi des composants de l'hôte qui traitent leurs entrées et sorties. Entretenir uniquement les systèmes invités laisse une partie essentielle de l'infrastructure hors du suivi. Le bon objectif est concret : **savoir quels hyperviseurs sont concernés, installer les correctifs adaptés et prouver qu'ils sont actifs**. L'inventaire et la préparation des maintenances rendent cette réponse plus rapide lors des alertes suivantes. C'est le rôle d'un [suivi régulier des CVE intégré à l'exploitation](/blog/suivi-cve-pourquoi-quotidien/). Vous avez besoin de qualifier votre parc ou d'organiser la correction de vos hôtes ? Découvrez notre [accompagnement en infogérance Linux](/infogerance/) ou [contactez-nous pour votre infrastructure de virtualisation](/contact/). ## Sources - pwn.ai — recherche PwnEscape et démonstrations - Proxmox — confirmation du noyau corrigé par l'équipe - Debian — versions corrigées de linux - Canonical — statut des branches Ubuntu - AWS — périmètre KVM/virtio-net autogéré et remédiation - VirtFusion — suivi de l'exposition et des correctifs ## FAQ : PwnEscape et les hôtes Linux ### Quel noyau Proxmox corrige PwnEscape ? L'équipe Proxmox confirme le correctif dans `proxmox-kernel-7.0.14-24-pve`, y compris sa variante signée. Vérifiez le paquet disponible dans votre dépôt et le noyau chargé après redémarrage. ### Mettre à jour les VM suffit-il ? Non. Dans le scénario d'évasion de VM, le composant à corriger est le noyau Linux de l'hôte de virtualisation. ### PwnEscape nécessite-t-elle la virtualisation imbriquée ? Non. Le chemin réseau virtio-net/TAP peut exposer un hôte vulnérable même lorsque la virtualisation imbriquée est désactivée.