Il y a des failles qu’on découvre après coup, et celles qu’on déniche avant que personne ne l’exploite. Januscape appartient à cette seconde catégorie. Celle-ci a été trouvée le 6 juillet 2026 par Hyunwoo Kim, connu sous le pseudo @v4bel.

Ce chercheur en cybersécurité indépendant l’a découverte en participant à un programme organisé par Google, baptisé kvmCTF, qui invite les chercheurs du monde entier à tenter de « sortir » d’une machine virtuelle pour aller compromettre la machine physique qui l’héberge.

Avant d’entrer dans le grand bain

Pour rappel, une machine virtuelle, ou VM, est un ordinateur simulé qui fonctionne à l’intérieur d’un vrai ordinateur : les grandes entreprises du cloud, comme Amazon (AWS) ou Google Cloud, découpent virtuellement leurs immenses serveurs physiques en plusieurs machines indépendantes, qu’elles louent séparément à différents clients. Chacune se comporte comme un ordinateur à part entière, avec son propre système et ses propres droits d’administrateur, alors qu’en réalité, plusieurs VM appartenant à des clients différents partagent le même serveur physique en coulisses.

C’est un logiciel appelé hyperviseur qui fait tourner ces VM et les isole les unes des autres : en théorie, ce qui se passe dans la VM d’un client ne doit jamais pouvoir affecter celle d’un autre client, ni la machine physique elle-même. « Sortir » d’une VM pour atteindre la machine hôte est donc considéré comme l’une des attaques les plus graves possibles dans le cloud, ce qui explique pourquoi Google récompense ce genre de découverte à hauteur de 250 000 dollars.

Mais voilà, Kim y est parvenu, et a nommé sa découverte Januscape. Elle est désormais officiellement référencée sous le nom CVE-2026-53359. Le bug se situe dans l’hyperviseur nommé KVM, chargé de faire fonctionner les VM sur les serveurs Linux équipés de processeurs Intel ou AMD.

À l’image de CopyFail, dévoilée en avril, une autre faille elle aussi restée cachée pendant plus d’une décennie, Januscape était présente, silencieuse, dans une quantité colossale de serveurs à travers le monde depuis août 2010.

Concrètement, comment ça marche ?

Pour comprendre Januscape, il faut d’abord comprendre un mécanisme de base de KVM. Une VM ne voit pas directement la mémoire physique de l’ordinateur qui l’héberge. Elle fonctionne avec ses propres repères internes et c’est justement KVM qui fait l’intermédiaire entre ces repères et la mémoire réellement disponible sur la machine, un peu comme un registre qui indique en permanence « telle donnée de la VM se trouve à tel endroit précis de la mémoire physique ».

Construire ce registre à partir de zéro à chaque fois qu’une VM démarre serait beaucoup trop lent et pour gagner du temps, KVM réutilise donc des blocs de mémoire déjà utilisés par ailleurs, dès qu’ils se libèrent, plutôt que d’en créer de nouveaux à chaque fois.

C’est précisément cette réutilisation qui pose problème dans le cas de Januscape. Pour décider si un bloc de mémoire est disponible et peut être recyclé, KVM ne vérifiait que son adresse attribuée, sans jamais vérifier à quoi ce bloc servait réellement juste avant.

Or un même emplacement mémoire peut, à des moments différents, contenir des types de données variés et remplir des fonctions distinctes selon le moment. En se fiant uniquement à l’adresse, KVM pouvait donc récupérer un bloc de mémoire en pensant qu’il contenait un certain type d’information, alors qu’il en contenait encore un autre. Résultat : les repères internes de KVM devenaient faux, et ses liens entre les blocs de mémoire et leurs adresses se retrouvaient brouillés.

Pour faire simple et ne pas perdre tout le monde : une VM c’est une machine dans une machine. // Source : Montage Numerama

Deux scénarios d’exploitation de la faille

Dans l’immense majorité des cas, le système d’exploitation détecte cette incohérence et arrête tout immédiatement, avant que la situation ne s’aggrave. C’est d’ailleurs ce que montre la démonstration publique de Kim, publiée sur X où l’on peut voir la machine physique planter d’un coup, ce qui entraîne dans sa chute toutes les autres machines virtuelles qui tournaient dessus au même moment, y compris celles d’autres clients, qui n’ont rien demandé.

Une faille déjà problématique, on vous l’accorde, mais Kim a identifié un second scénario, bien plus dangereux. Si ce bloc de mémoire est réattribué à un nouvel usage avant que le système ait fini de nettoyer complètement son ancien contenu, alors cette opération de nettoyage qui arrive en retard va écrire des données au mauvais endroit, dans une zone de mémoire qui, entre-temps, a changé de fonction et sert désormais à autre chose.

Certes, l’attaquant ne peut pas choisir précisément ce qui est écrit à cet endroit, mais il peut influencer où cette écriture erronée va se produire. Un contrôle qui, même partiel, peut suffire à un attaquant expérimenté de progressivement élever ses privilèges et, à terme, prendre le contrôle total de la machine physique, avec les droits d’administrateur les plus élevés qui existent sur un système Linux, ce qu’on appelle les droits root.

Kim affirme posséder un exploit complet et fonctionnel permettant d’aller jusque-là, mais il ne l’a pas rendu public, précisément pour éviter qu’il ne soit utilisé par des personnes malveillantes avant que tous les serveurs concernés n’aient pu être corrigés.

Qui est concerné, et comment se protéger

Pour que cette faille soit réellement exploitable, deux conditions doivent être réunies en même temps.

D’abord, il faut disposer des droits root à l’intérieur de la VM visée. Mauvaise (ou bonne) nouvelle, selon le point de vue : c’est la situation par défaut pour la plupart des VM louées dans le cloud.

Ensuite, il faut que la machine physique qui héberge la VM ait activé une fonctionnalité appelée virtualisation imbriquée. Il s’agit de la possibilité de faire tourner une VM à l’intérieur d’une autre VM. Cette fonctionnalité n’est pas activée partout : elle sert surtout dans des cas particuliers, par exemple quand un client cloud a lui-même besoin de créer ses propres VM à l’intérieur de la VM qu’il loue. Mais quand elle est active, elle ouvre justement la porte au type de manipulation mémoire exploité par Januscape.

Les environnements les plus exposés sont donc les clouds « multi-tenant », un terme qui désigne les infrastructures où plusieurs clients différents partagent les mêmes machines physiques, comme c’est le cas chez AWS ou Google Cloud.

Le correctif a été intégré au noyau principal le 16 juin 2026 et a ensuite été repris et diffusé dans plusieurs versions stables de Linux début juillet.