Zapscape CVE-2026-64561 : évasion KVM critique sur Linux

Une faille vieille de dix-huit ans dans la virtualisation Linux

Le 6 août 2026, le chercheur en sécurité Hyunwoo Kim a procédé à la divulgation publique coordonnée d une vulnérabilité critique qu il avait identifiée dans le sous-système KVM (Kernel-based Virtual Machine) du noyau Linux. Référencée CVE-2026-64561 et nommée Zapscape par son découvreur, cette faille est présente dans le code de gestion des shadow page tables depuis plus de dix-huit ans, traversant des dizaines de versions du noyau sans jamais être détectée.

KVM est le module de virtualisation natif du noyau Linux, utilisé par la quasi-totalité des fournisseurs de cloud public — AWS, Google Cloud Platform, Microsoft Azure et des dizaines d opérateurs régionaux — ainsi que par d innombrables entreprises gérant leurs propres infrastructures privées. Chaque fois qu une machine virtuelle tourne sur un serveur Linux, KVM est, le plus souvent, le composant qui assure son isolation vis-à-vis de la machine hôte et des autres VMs co-résidentes.

Le bogue réside dans la gestion des shadow memory management units (shadow MMU) utilisées pour la virtualisation de la mémoire lors des scénarios de virtualisation imbriquée (nested virtualization). Plus précisément, deux chemins de gestion des page faults valident le shadow root avant d entreprendre la réclamation de shadow pages, là où la logique correcte exigerait que cette validation intervienne après. Cette inversion crée une condition use-after-free : KVM continue de construire des mappings de mémoire en s appuyant sur une racine qu une opération de réclamation a déjà invalidée et libérée. La mémoire libérée reste accessible pendant un court laps de temps, fenêtre qu un attaquant peut exploiter pour y écrire des données arbitraires et déclencher une exécution de code.

Dans le scénario le plus grave, un attaquant disposant de privilèges noyau à l intérieur d une machine virtuelle L1 (un invité de premier niveau) peut s échapper de l isolation KVM et exécuter des commandes sur l hôte physique avec des privilèges root. Concrètement, un client ayant loué une seule instance cloud peut potentiellement prendre le contrôle de l ensemble du serveur physique et de toutes les VMs qui y coexistent. Le chercheur a également démontré un scénario de déni de service permettant de provoquer un kernel panic sur l hôte, interrompant instantanément l ensemble des VMs hébergées.

La chronologie de la divulgation mérite d être soulignée. Kim a signalé la vulnérabilité à [email protected] le 11 juillet 2026. Un patch a été proposé et intégré dans le noyau upstream le 21 juillet, soit en dix jours. La soumission à la liste linux-distros a eu lieu le 1er août sous embargo de cinq jours. L identifiant CVE-2026-64561 a été assigné le 4 août, et la divulgation publique complète, accompagnée d un exploit proof-of-concept (PoC), est intervenue le 6 août 2026.

La disponibilité d un PoC opérationnel transforme radicalement le niveau de risque. Avant sa publication, la vulnérabilité n était accessible qu à des attaquants disposant de capacités de recherche offensive avancées. Désormais, le code est accessible à tout acteur motivé, ce qui réduit considérablement la barrière à l entrée. D après les analyses relayées par SecurityOnline, l exploit PoC cible les configurations de virtualisation imbriquée, une fonctionnalité activée par défaut sur de nombreuses plateformes cloud proposant des offres de VMs burstables ou des environnements bare-metal as a service.

Les distributions affectées identifiées incluent Debian 13, Ubuntu 24.04 LTS, Red Hat Enterprise Linux 9, Rocky Linux 9 et OpenCloudOS. Les correctifs ont déjà été backportés par la plupart des éditeurs, mais la fenêtre entre la publication du PoC et l application effective des patchs dans les parcs représente une exposition critique, d autant que de nombreuses équipes opèrent avec des cycles de patch de plusieurs semaines. Au moment de la rédaction, CVE-2026-64561 ne figure pas encore dans le catalogue KEV de la CISA, ce qui indique qu aucune exploitation active n a été confirmée en production — mais le délai avant une exploitation active pourrait se mesurer en jours.

Selon Phoronix et The Hacker News, qui ont relayé la divulgation dès le 6 août, la faille n est pas distante : elle nécessite d abord d obtenir des privilèges noyau au sein d une VM invitée. Dans un contexte de cloud public, cela reste cependant parfaitement accessible pour un attaquant contrôlant un workload conteneurisé mal isolé ou bénéficiant d une élévation de privilèges préalable à l intérieur du guest. La combinaison d une élévation locale dans le guest suivie de l exploitation de Zapscape constitue une chaîne d attaque réaliste et particulièrement dangereuse.

Le spectre de l évasion de VM : un problème systémique pour le cloud multi-tenant

Zapscape s inscrit dans une longue série de vulnérabilités d évasion de machine virtuelle qui hantent l industrie du cloud depuis ses débuts. Des failles comme VENOM (CVE-2015-3456), qui ciblait l émulateur de disquette QEMU, ont démontré depuis longtemps que la frontière entre une VM et son hôte n est jamais absolue. Chaque couche de la pile de virtualisation représente une surface d attaque potentielle.

Ce qui distingue Zapscape des précédentes vulnérabilités de ce type, c est son âge et sa localisation dans un composant aussi central. Le code affecté était présent depuis dix-huit ans sans être détecté, traversant des cycles de révision intensifs et des audits de sécurité répétés. Cela soulève des questions fondamentales sur la soutenabilité des modèles de revue de code humaine pour des bases de code aussi complexes que le noyau Linux, qui compte aujourd hui plus de trente millions de lignes. Des outils d analyse statique comme CodeQL ou Semgrep n auraient peut-être pas non plus détecté cette race condition temporelle sans configurations spécifiques aux chemins d exécution de KVM.

Pour les entreprises utilisant des architectures multi-cloud ou hybrides, Zapscape crée un scénario de risque particulièrement préoccupant. Dans un environnement où des workloads sensibles cohabitent sur des hôtes partagés avec d autres tenants, même une exploitation partielle peut avoir des conséquences contractuelles, réglementaires et de réputation considérables. Au regard du RGPD et des exigences NIS2, toute compromission d un hyperviseur hébergeant des données personnelles constitue potentiellement une violation de données à notifier à l autorité compétente dans les 72 heures.

La communauté du noyau Linux a réagi rapidement. La rapidité du merge upstream témoigne du sérieux avec lequel l équipe de sécurité du kernel prend ce type de rapports. Néanmoins, le délai entre le merge et la mise à jour effective des parcs de production reste le maillon faible. En environnement cloud managé, les grands fournisseurs disposent généralement de processus de mise à jour transparente — live patching ou migration à chaud — qui peuvent réduire ce délai, mais ces mécanismes ne couvrent pas toujours toutes les configurations de virtualisation imbriquée. Les opérateurs d infrastructures on-premise doivent impérativement planifier une mise à jour d urgence hors cycle.

Ce qu il faut retenir

• Zapscape (CVE-2026-64561) est une faille use-after-free dans KVM Linux permettant l évasion de VM vers l hôte avec privilèges root ; un PoC est public depuis le 6 août 2026.
• Toutes les distributions Linux majeures (Debian 13, Ubuntu 24.04, RHEL 9, Rocky Linux 9) sont affectées ; les correctifs sont disponibles et doivent être appliqués en urgence.
• En l absence d exploitation active confirmée (pas de KEV CISA au 7 août), la fenêtre de remédiation est encore ouverte — mais le PoC public la réduit considérablement : priorité maximale sur les hôtes KVM exposés à de la virtualisation imbriquée.