Une vulnérabilité découverte dans le noyau Linux menace l’isolation des machines virtuelles sur les serveurs KVM. Baptisée PwnEscape et notée 9,3/10 en gravité, elle pousse déjà plusieurs hébergeurs à prendre des mesures d’urgence.

La divulgation de PwnEscape a déclenché une course aux correctifs des différentes distributions Linux. ©MAFPHOTOART8 x Shutterstock
La divulgation de PwnEscape a déclenché une course aux correctifs des différentes distributions Linux. ©MAFPHOTOART8 x Shutterstock

Pour un hébergeur cloud, l’une des pires situations serait de voir un client prendre le contrôle du serveur qui héberge ses machines virtuelles. C’est précisément le risque soulevé par PwnEscape (CVE-2026-99999), une faille critique du noyau Linux révélée par les chercheurs de pwn.ai.

Le problème concerne les infrastructures utilisant KVM, une technologie de virtualisation largement répandue sous Linux. Dans les configurations exposées, un attaquant disposant de privilèges élevés dans une machine virtuelle peut exploiter son interface réseau virtuelle de type virtio pour franchir les protections qui l’isolent du serveur hôte. Il pourrait alors compromettre ce serveur et, potentiellement, les ressources d’autres clients.

Une simple erreur réseau ouvre une brèche dans Linux

La faille ne se trouve pas directement dans KVM, mais dans la manière dont Linux traite certains paquets réseau. Lorsqu’une machine virtuelle transmet des données, elle peut confier au noyau de l’hôte le calcul de leur somme de contrôle, une opération destinée à vérifier l’intégrité des informations échangées.

Or, une mauvaise validation permet de détourner cette opération pour modifier une partie du paquet que Linux avait déjà vérifiée. Cette manipulation peut alors provoquer des accès mémoire qui n’auraient jamais dû être autorisés.

Des chercheurs de pwn.ai ont ainsi réussi à récupérer des informations présentes dans la mémoire du serveur hôte. Ils sont ensuite parvenus, sur leurs propres machines de laboratoire, à exécuter du code avec les privilèges administrateur. Leurs essais ont également provoqué le plantage d’un serveur et des machines virtuelles qu’il hébergeait.

Vercel confirme également qu’une fuite de mémoire de l’hôte a été démontrée sur ses infrastructures de production dans le cadre de son programme de recherche de vulnérabilités. La prise de contrôle complète du serveur a, elle, été obtenue sur les machines de laboratoire des chercheurs.

Ces démonstrations confirment la gravité de PwnEscape, même si aucune exploitation malveillante sur des infrastructures de production n’a été publiquement établie à ce stade.

Les hébergeurs commencent à sécuriser leurs serveurs

La divulgation de PwnEscape a déclenché une course aux correctifs. Le patch a été intégré au code réseau de Linux le 8 octobre, avant d’être repris dans le noyau principal quelques jours plus tard, le 14 octobre exactement.

Debian propose déjà des versions corrigées, notamment les noyaux 6.1.190-1 pour Bookworm et 6.12.113-1 pour Trixie. Chez Ubuntu, plusieurs versions étaient encore en cours d’évaluation au moment de notre vérification.

Les hébergeurs n’ont toutefois pas tous choisi la même méthode. Selon Heise, Netcup a commencé à redémarrer ses serveurs de virtualisation pour appliquer les corrections. Hetzner a de son côté mis en place une protection temporaire reposant sur eBPF, une technologie permettant notamment de filtrer certains comportements directement dans le système.

Pour les clients utilisant un serveur virtuel, la correction de cette faille dépend avant tout de l’hébergeur. Ce sont les machines hôtes qui doivent être protégées, et l’installation d’un nouveau noyau nécessite généralement un redémarrage.

Trois jours et 700 dollars pour découvrir une faille critique

L’histoire de PwnEscape est aussi révélatrice de la place prise par l’intelligence artificielle dans la cybersécurité.

Les chercheurs expliquent avoir découvert la vulnérabilité en seulement trois jours, en s’appuyant sur un système d’analyse automatisé utilisant notamment GPT-5.6 Sol. Le coût des requêtes au modèle serait resté inférieur à 700 dollars.

L'IA n’a pas travaillé seule. Les chercheurs ont orienté les investigations, vérifié les hypothèses et confirmé les résultats. Mais cette méthode leur a permis d’explorer rapidement un volume considérable de code. La correction, elle, a demandé plusieurs semaines de travail et d’échanges avec les mainteneurs du noyau Linux.

À découvrir
Quelles sont les meilleures distributions Linux ? Comparatif 2026
Comparatifs services
À découvrir
Meilleur hébergeur web, le comparatif en 2026
Comparatifs services
Foire aux questionsContenu généré par l’IA
Qu’est-ce qu’un VM escape sur une infrastructure KVM, et pourquoi est-ce critique pour un hébergeur ?

Un VM escape désigne une attaque où un acteur, depuis une machine virtuelle (VM), parvient à sortir de son environnement isolé pour interagir avec le système hôte. Sur KVM, l’hôte Linux pilote le matériel et orchestre plusieurs VM ; si l’hôte est compromis, la séparation entre clients peut s’effondrer. L’impact va au-delà de la VM attaquante : accès à la mémoire de l’hôte, altération de la configuration du serveur, et possibilité d’atteindre d’autres VM cohébergées. C’est critique en cloud multi-tenant, car l’isolation est la base de la sécurité et du modèle économique.

À quoi sert Virtio dans le réseau des machines virtuelles, et en quoi peut-il devenir un point d’attaque ?

Virtio est une interface paravirtualisée qui permet à une VM de dialoguer efficacement avec l’hôte pour des fonctions comme le réseau et le stockage, avec moins de surcharge qu’une émulation matérielle complète. Concrètement, la VM transmet des paquets à une couche côté hôte qui les traite via la pile réseau Linux. Si cette pile ou une étape associée (validation, offload, copie en mémoire) comporte un bug, la VM peut déclencher un comportement anormal sur l’hôte. Virtio devient alors un point d’entrée privilégié, car il est conçu pour des échanges rapides et fréquents entre invité et hôte.

Qu’est-ce que le checksum offload (déport de somme de contrôle) dans la pile réseau Linux, et comment un bug peut mener à une fuite mémoire ou à l’exécution de code ?

Le checksum offload consiste à laisser l’hôte (ou le matériel) calculer la somme de contrôle d’un paquet réseau à la place de l’émetteur, pour gagner en performance. Ce mécanisme s’appuie sur des métadonnées décrivant quelles parties du paquet sont couvertes par les vérifications d’intégrité. Si le noyau valide une structure puis autorise ensuite une modification de champs pourtant supposés figés, on crée une incohérence entre ce qui a été vérifié et ce qui est réellement traité. Dans le pire cas, cela peut provoquer des lectures/écritures mémoire hors limites : fuite d’informations sensibles en mémoire, crash, voire exécution de code avec de hauts privilèges sur l’hôte.