PwnEscape partie 2 : l'évasion de microVM Firecracker qui donne root sur l'hôte depuis un invité

PWN Research a publié la suite de son analyse PwnEscape : une démonstration d'évasion de microVM Firecracker qui aboutit à l'exécution de code en tant que root sur l'hôte, lancée depuis l'intérieur d'un invité. Le chercheur Paulos Yibelo part de la primitive d'accès à la mémoire de l'hôte décrite dans la partie 1 (la faille noyau CVE-2026-99999), localise le processus Firecracker en mémoire, retrouve les registres sauvegardés d'un thread vCPU en plein appel KVM_RUN, puis détourne son flot d'exécution pour faire exécuter un appel système choisi par l'attaquant. Le point important pour quiconque administre un serveur dédié hébergeant des machines virtuelles : la démonstration vise Firecracker 1.16.1 sur x86-64 lancé sans le jailer, et elle n'exploite aucun bug du code de Firecracker. La faille est dans le noyau Linux de l'hôte. La microVM, souvent présentée comme la dernière barrière d'isolation, hérite des vulnérabilités du noyau sur lequel elle repose.

Sources : Firecracker VM Escape: PwnEscape Part 2 et PwnEscape Part 1 (PWN Research, Paulos Yibelo), bilan du challenge Vercel Sandbox (14 octobre 2026), note de recherche Cloud Security Alliance (18 octobre 2026), advisory Proxmox PSA-2026-00068-1 (16 octobre 2026), documentation Firecracker (jailer, seccomp, production host setup).

Ce que PWN Research a démontré sur Firecracker

Firecracker est un moniteur de machine virtuelle (VMM) open source écrit en Rust par AWS. Il tourne en espace utilisateur au-dessus de KVM, l'hyperviseur intégré au noyau Linux, et crée des microVM : des machines virtuelles minimalistes qui démarrent en moins de 125 ms, n'émulent que cinq périphériques et ajoutent moins de 5 Mio de surcoût mémoire par instance. C'est la brique qui fait tourner AWS Lambda et de nombreuses plateformes de sandbox pour agents IA et de serverless. Son argument de vente est l'isolation : chaque charge non fiable s'exécute dans sa propre machine virtuelle, derrière la frontière de virtualisation.

La partie 2 de PwnEscape montre que cette frontière peut être franchie quand le noyau hôte est vulnérable. La configuration de test est un Firecracker 1.16.1 sur architecture x86-64, avec un noyau hôte 7.0.0-1011-aws et un noyau invité 6.18.44+. Le binaire est lancé directement en root via systemd-run, épinglé à un cœur avec taskset, et surtout sans le jailer, le composant de confinement de Firecracker. À partir de la primitive mémoire de la partie 1, la chaîne démontrée enchaîne quatre étapes, au niveau conceptuel :

• Localiser l'invité dans la mémoire de l'hôte : un marqueur unique est placé dans une page de l'invité, puis retrouvé côté hôte en parcourant les structures de pagination de la virtualisation pour obtenir l'adresse physique de cette page.
• Retrouver le processus Firecracker : en remontant les tables de pages de l'hôte, le chercheur identifie le binaire Firecracker par sa signature et récupère son décalage de chargement, ce qui contourne l'ASLR (la randomisation d'adresses).
• Trouver le thread vCPU en plein travail : un repéreur de contexte cherche les registres sauvegardés d'un thread qui exécute l'appel KVM_RUN (la boucle principale d'un vCPU), reconnaissable à son numéro d'appel système et à l'adresse de retour dans le code de Firecracker.
• Détourner l'exécution : le pointeur d'instruction sauvegardé est réécrit pour pointer vers une fonction existante de Firecracker, de sorte qu'au retour dans l'espace utilisateur, le VMM exécute une opération choisie par l'attaquant. Les quelques mots de pile modifiés sont ensuite restaurés.

Résultat annoncé : une écriture déclenchée depuis l'invité provoque l'exécution d'un appel système sous l'identité root de l'hôte, le processus Firecracker continue de tourner, et la machine virtuelle reste joignable en SSH. Aucune erreur noyau n'est observée côté hôte. PWN Research présente ce travail comme une démonstration de CVE-2026-99999 sur une installation Firecracker, pas comme une attaque prête à l'emploi : l'écriture contrôlée a été montrée sur le banc d'essai KVM et Firecracker du chercheur, pas sur un service en production.

Pourquoi ce n'est pas une faille de Firecracker

Le point le plus contre-intuitif de cette publication est qu'elle ne révèle aucune vulnérabilité dans le code de Firecracker. La faille exploitée est CVE-2026-99999, un défaut de type TOCTOU dans le traitement des checksums IPv4 de la pile réseau virtio du noyau Linux. C'est cette faille, présente dans le noyau de l'hôte, qui donne à l'invité un accès en lecture et en écriture à la mémoire physique de la machine. Firecracker n'est ici que la cible sur laquelle cette primitive est transformée en exécution de code.

La conséquence est importante pour un administrateur. La question n'est pas « quel hyperviseur ou quel runtime de microVM utiliser », parce que le même noyau hôte sert KVM quel que soit le VMM placé au-dessus : QEMU, Firecracker, Cloud Hypervisor. Tant que le noyau de l'hôte n'est pas corrigé, un invité malveillant dispose de la même primitive, quelle que soit la finesse du VMM. C'est exactement ce que la note de recherche de la Cloud Security Alliance résume : de nombreuses plateformes traitent la frontière invité-hôte comme la couche de défense finale, or cette couche hérite des vulnérabilités du noyau hôte.

La microVM n'est pas une barrière magique

L'intérêt d'une microVM par rapport à un conteneur est réel : elle ajoute une vraie frontière matérielle de virtualisation là où un conteneur partage directement le noyau de l'hôte. Mais « vraie frontière » ne veut pas dire « frontière infranchissable ». La défense d'une installation de virtualisation est une pile de couches, et la frontière VM n'en est qu'une. PwnEscape rappelle que ces couches se complètent au lieu de se remplacer.

Autrement dit, patcher le noyau hôte supprime la faille, et le confinement (jailer, namespaces, seccomp) réduit les dégâts si une faille future, encore inconnue, refait surface. Les deux sont nécessaires. Lancer un VMM en root et sans confinement, comme dans la démonstration, additionne les deux risques : la primitive existe, et rien ne borne ce qu'un VMM détourné peut faire.

Conteneur, microVM, machine virtuelle classique : ce qui est partagé avec l'hôte

Pour comprendre la portée de PwnEscape, il faut savoir ce que chaque technologie d'isolation partage avec le serveur physique qui l'héberge. Les trois reposent sur le même matériel (hardware) et, pour les deux formes de virtualisation, sur la même extension du processeur (Intel VT ou AMD-V) exposée par le noyau Linux via KVM. Ce qui change, c'est la quantité de code de l'hôte que l'invité peut atteindre.

Une microVM se situe donc entre les deux : elle apporte à des environnements non fiables l'isolation d'un vrai système d'exploitation invité, avec un démarrage et une empreinte mémoire proches de ceux d'un conteneur. Mais elle ne supprime pas la dépendance au noyau de l'hôte. Les pilotes virtio, qui transportent le réseau et le disque de l'invité, sont du code du noyau hôte, et c'est précisément là que se trouve CVE-2026-99999. La chaîne PwnEscape part donc d'un invité virtualisé, microVM ou VM classique. Un conteneur n'emprunte pas ce chemin, mais il dispose de la totalité des appels système du même noyau : sur un serveur dédié qui héberge à la fois des containers et des serveurs virtuels, c'est un seul et même noyau Linux à maintenir à jour.

Qui fait tourner des microVM Firecracker sur un serveur

Firecracker n'est pas réservé aux hyperscalers. On le retrouve chez de nombreuses plateformes de calcul à la demande, et surtout dans deux cas d'usage qui se généralisent sur les serveurs dédiés : le serverless (exécuter une fonction éphémère par requête) et les sandboxes d'agents IA (donner à un agent autonome une machine jetable où exécuter du code qu'aucun humain n'a relu). C'est précisément le scénario de notre guide isoler un agent IA dans une microVM sur un serveur dédié, où chaque agent reçoit sa propre microVM au-dessus de KVM.

Les agents IA cumulent trois facteurs qui aggravent l'enjeu, pointés par la Cloud Security Alliance : ils exécutent du code que personne n'a relu, plusieurs locataires partagent souvent le même hôte, et ils disposent d'un accès réseau sortant. Une injection d'instruction ou un outil piégé peut suffire à obtenir l'accès initial dans l'invité, qui est le seul prérequis de la chaîne. Et si l'attaque fait planter l'hôte au lieu de le compromettre proprement, toutes les machines virtuelles de la machine tombent avec lui. Le même type d'incident, un agent autonome qui sort de son bac à sable, a déjà fait l'actualité avec l'agent de pentest ARTEX échappé chez WorkOS.

Cette publication n'est pas un cas de laboratoire isolé. La faille sous-jacente a été trouvée par Paulos Yibelo pendant le challenge à un million de dollars organisé par Vercel sur sa plateforme Vercel Sandbox, qui fait tourner le code client dans des microVM Firecracker. Sur 1 285 soumissions en deux semaines, la découverte la plus grave était ce défaut de la pile réseau du noyau Linux : la fuite de mémoire a été démontrée contre les sandboxes de production de Vercel, le plantage et l'exécution de code sur les machines KVM et Firecracker du chercheur.

Ce qu'un admin qui héberge des microVM doit vérifier

Si vous faites tourner des microVM Firecracker sur votre propre serveur, voici la liste de contrôle à passer en revue, de la plus urgente à la plus structurelle. Elle vaut aussi pour un hôte Proxmox VE ou tout hyperviseur KVM, puisque la faille est dans le noyau commun.

Patcher le noyau hôte contre CVE-2026-99999

La seule mesure qui supprime la faille est la mise à jour du noyau de l'hôte, suivie d'un redémarrage. Mettre à jour le noyau de l'invité ne sert à rien : le bug est dans la pile réseau du noyau hôte. Connectez-vous à l'hôte (pas à la microVM) et relevez sa version avec uname -r, puis comparez :

Sur un hôte Debian ou Ubuntu, la mise à jour passe par le gestionnaire de paquets, suivie d'un redémarrage pour charger le nouveau noyau :

sudo apt update && sudo apt full-upgrade -y
sudo reboot

Après le redémarrage, confirmez avec uname -r que la version active est bien une version corrigée. Si votre distribution n'a pas encore publié de package noyau intégrant le correctif, configurez les mises à jour de sécurité automatiques pour l'appliquer dès sa disponibilité. Comme un redémarrage interrompt brièvement toutes les microVM de l'hôte, planifiez-le hors des heures de pointe, et sauvegardez vos données au préalable.

Redémarrer l'hôte sans couper les serveurs virtuels : cluster et migration

Le correctif n'est actif qu'après un redémarrage de la machine serveur, et c'est souvent ce redémarrage qui fait reculer les administrateurs. Sur un serveur physique isolé, il n'y a pas d'échappatoire : toutes les microVM et machines virtuelles hébergées s'arrêtent le temps que l'hôte revienne. Prenez des sauvegardes récentes avant l'opération, prévenez vos utilisateurs et notez l'adresse IP de l'hôte et sa console de secours pour reprendre la main si le nouveau noyau ne démarre pas. Un tableau de bord comme Pulse pour Proxmox VE, Proxmox Backup Server et Docker vous alerte dès qu'une VM n'est pas revenue ou qu'un backup a échoué.

Dans un cluster Proxmox VE, le redémarrage peut se faire sans interruption grâce à la migration à chaud. La commande qm migrate avec l'option --online déplace une VM en cours d'exécution vers un autre nœud : la source envoie le contenu de la RAM au nœud cible de façon asynchrone, renvoie les pages modifiées en plusieurs passes, puis suspend très brièvement la VM pour transférer le dernier écart. Les disques locaux peuvent aussi être envoyés vers la cible, et le stockage partagé évite même cette copie. Deux contraintes documentées par Proxmox : la migration à chaud exige la même architecture de processeur des deux côtés, et une migration entre hôtes Intel et AMD n'est pas garantie. Videz le nœud, redémarrez-le, vérifiez son noyau, puis rapatriez les VM, et répétez sur chaque nœud. Attention au sens de la migration : déplacer une VM vers un nœud pas encore patché la ré-expose à la faille. Pour piloter plusieurs clusters pendant cette campagne de patch, un tableau de bord multi-clusters comme PegaProx évite d'oublier un hôte.

Si votre serveur physique est en housing dans un data center, la situation est la même que pour un serveur dédié : l'hébergeur fournit l'alimentation, le réseau et l'accès physique, mais le noyau de l'hôte reste sous votre responsabilité. À l'inverse, si vous louez des serveurs virtuels, ce sont les noyaux des hôtes de l'hébergeur qu'il faut questionner.

Durcir une installation Firecracker : jailer, seccomp, namespaces

Le patch noyau ferme la faille du jour. Le confinement, lui, prépare l'hôte à la prochaine. C'est la logique « partez du principe qu'un nouveau jour zéro arrivera » que recommandait le cabinet Trail of Bits dans le bilan Vercel. La démonstration PwnEscape a été faite sans aucun de ces contrôles : Firecracker en root, sans jailer, sans namespaces. Voici les couches qui auraient borné ce qu'un VMM détourné pouvait atteindre.

• Le jailer est le composant de confinement de Firecracker. Il place le VMM dans un chroot via pivot_root, le met dans un namespace de montage (et, en option, de PID et de réseau), puis abandonne les privilèges en basculant sur l'utilisateur et le groupe non privilégiés que vous indiquez. La documentation de production recommande de lancer Firecracker avec le jailer, ou avec des contraintes au moins aussi strictes, et de dédier un utilisateur POSIX par instance.
• Les filtres seccomp limitent les appels système que Firecracker peut adresser au noyau hôte, au strict minimum, et sont chargés thread par thread avant l'exécution de code invité. Ils sont compilés dans le binaire et actifs par défaut. La documentation déconseille explicitement --no-seccomp et --seccomp-filter en production : gardez les filtres par défaut.
• Les namespaces et cgroups cloisonnent le VMM et bornent ses ressources (mémoire, processeurs, entrées-sorties disque). Sur un hôte Proxmox, le même principe de segmentation s'applique au réseau avec le SDN pour isoler les réseaux virtuels.
• Le filtrage réseau sur l'hôte. Firecracker ne filtre aucun trafic : c'est à l'hôte de le faire. Configurez nftables pour borner les adresses IP et les ports que les invités peuvent joindre, en particulier les points d'accès aux métadonnées, le DNS interne et le réseau de gestion.
• Désactiver la console série en production (8250.nr_uarts=0), désactiver le SMT et le KSM en environnement multi-locataire, et ne jamais mutualiser une microVM entre plusieurs clients : un processus Firecracker doit correspondre à la charge d'un seul locataire.

Au-delà de Firecracker, les bases d'hygiène d'un hôte de virtualisation restent valables : accès SSH par clé et sans login root, surveillance des ressources (processeur, RAM, espace disque) pour repérer un comportement anormal, et premiers réglages de sécurisation d'un serveur dédié si ce n'est pas déjà fait. Nos autres tutoriels serveur couvrent les configurations courantes d'un hôte de virtualisation. Si vos microVM sont hébergées chez un prestataire, demandez-lui par écrit si les noyaux de ses hôtes sont corrigés : vous ne pouvez pas appliquer ce patch depuis l'intérieur de votre machine virtuelle.

Chronologie de PwnEscape

Questions fréquentes sur PwnEscape partie 2

Les réponses ci-dessous s'adressent aux administrateurs de serveurs qui hébergent des machines virtuelles et des microVM.

Conclusion

PwnEscape partie 2 ne révèle pas une faille de Firecracker, mais montre comment une faille du noyau hôte, CVE-2026-99999, suffit à transformer un invité en root sur l'hôte, y compris au-dessus d'un VMM minimaliste réputé pour son isolation. Le message pour un administrateur qui héberge des microVM est double. D'abord, la microVM n'est pas une barrière magique : elle hérite des vulnérabilités du noyau sur lequel elle repose, et la seule mesure qui supprime cette faille est le patch du noyau hôte suivi d'un redémarrage. Ensuite, le confinement compte autant que le patch : un VMM lancé en root et sans jailer, comme dans la démonstration, n'offre aucune seconde ligne de défense le jour où une nouvelle faille apparaît. Vérifiez votre version de noyau avec uname -r, appliquez le correctif, activez le jailer et les filtres seccomp, et traitez le noyau de l'hôte comme une partie à part entière de votre périmètre de confiance sur votre serveur dédié ou votre VPS Linux.