PwnEscape (CVE-2026-99999) est une faille critique découverte dans le noyau Linux, et qui a permis, en laboratoire, de s’évader d’une VM KVM. Voici ce qu’il faut savoir à propos de cette faille.
Tout a commencé par un défi lancé le 18 août 2026 par Vercel : un million de dollars de primes pour qui parviendra à briser l’isolation de Vercel Sandbox, son service qui exécute le code des clients dans des micro-VM. Dès le troisième jour, Paulos Yibelo, chercheur chez pwn.ai, envoie un rapport… qui ne concerne pas vraiment Vercel. Le défaut se trouve dans la pile réseau du noyau Linux, une couche sur laquelle s’appuient presque tous les grands fournisseurs cloud pour isoler leurs clients.
Alors même si personne n’a percé l’isolation de Vercel Sandbox, la découverte de ce chercheur n’est pas anodine. D’ailleurs, dans le bilan de son événement publié le 14 octobre, Vercel estime que c’est le signalement le plus important associé à ce défi : c’est d’ailleurs la seule faille jugée critique, sur 1 285 rapports reçus. De son côté, Ubuntu lui attribue un score CVSS 3.1 de 9,3 sur 10.
Pour exploiter cette vulnérabilité associée à la référence CVE-2026-99999, un attaquant doit être capable d’exécuter du code dans une VM. Mais bon, ce n’est pas vraiment un problème, car c’est déjà ce que proposent les plateformes cloud, les services de CI/CD et les sandbox pour agents IA. Dans certains cas, faire tourner le code d’inconnus, c’est leur rôle.
Une somme de contrôle qui réécrit l’en-tête IPv4
Pour gagner en performances, Linux peut différer le calcul de la somme de contrôle (checksum) d’un paquet réseau. Dans ce cas, le paquet circule alors dans l’état CHECKSUM_PARTIAL, avec deux métadonnées, csum_start et csum_offset, qui indiquent où le calcul démarre et où le résultat doit être écrit. Le problème, c’est que ces métadonnées peuvent être fournies par la VM invitée.
Le rapport technique de pwn.ai apporte d’ailleurs des précisions sur la séquence en question. L’hôte analyse un en-tête IPv4 classique de 20 octets, puis la fonction skb_checksum_help() complète la somme de contrôle juste avant la fragmentation. Avec des métadonnées malformées, cette écriture tombe dans l’en-tête IPv4 déjà validé : le premier octet passe de 0x45 à 0x4f, et le champ IHL annonce désormais un en-tête de 60 octets.
Au moment de découper le paquet, la fonction ip_do_fragment() croit donc que l’en-tête fait 60 octets, alors que le paquet ne contient que 28 octets de données valides. Pour combler l’écart, le noyau lit plus loin, dans sa propre mémoire. Ces 32 octets, étrangers au paquet, sont recopiés dans l’en-tête sous forme d’options IP et envoyés sur le réseau, où l’attaquant n’a plus qu’à les récupérer.
En résumé, le noyau vérifie le paquet, le laisse ensuite être modifié à la demande de l’invité, puis se fie à cette version modifiée. “Différentes parties de Linux étaient autorisées à faire confiance à différentes versions du même paquet”, résument les chercheurs.
En exploitant cette faille surnommée PwnEscape, les chercheurs sont parvenus à aller jusqu’à l’exécution de code root sur l’hôte, mais pas de façon systématique. Voici les trois démonstrations réalisées :
Fuite de mémoire de l’hôte : démontrée sur les sandbox de production de Vercel, de façon continue tant que l’invité envoie des paquets.
Plantage de l’hôte : deux paquets suffisent, d’après Vercel, sur des machines KVM et Firecracker du chercheur configurées comme celles de Vercel.
Exécution de code root sur l’hôte : pwn.ai affirme avoir obtenu des écritures ciblées de 64 octets dans la mémoire du noyau, puis exécuté une commande root sur l’hôte, sur quatre démarrages à froid. Là encore, uniquement sur ses propres machines.
Le correctif concerne le noyau de l’hôte
Le correctif de sécurité a été intégré dans le commit 6785011f8b16 signé par Michael S. Tsirkin (Red Hat). Afin de contrer cette faille de sécurité, le comportement a été ajusté : avant de calculer la somme de contrôle, le noyau vérifie qu’elle ne risque pas d’écraser l’en-tête IPv4. Si c’est le cas, le paquet est rejeté. Intégrée au noyau Linux le 14 octobre 2026, cette protection n’est qu’une première étape : le filtrage des paquets malformés dès leur arrivée demande encore du travail.
Les premières versions stables corrigées seraient les 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11. Debian a déjà réagi pour Debian 13 Trixie : le bulletin DSA-6568-1 livre le noyau 6.12.113, d’après le tracker de Debian. En revanche, Debian 12 Bookworm reste vulnérable à l’heure où j’écris ces lignes. Ubuntu indique toujours que ses noyaux sont en cours d’évaluation.
Pour finir, une précision importante : c’est le noyau de l’hôte qu’il faut mettre à jour en priorité, pas celui des VM.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.