« Nous devrons faire mieux la prochaine fois » : OVHcloud raconte comment ses équipes ont patché Januscape, la faille qui dormait depuis 16 ans dans Linux

Une faille critique nommée Januscape (référencée CVE-2026-53359) a été découverte dans le noyau Linux, précisément dans le sous-système de virtualisation KVM (Kernel-based Virtual Machine), qui permet de faire tourner des machines virtuelles sur un serveur physique. Cette faille existait depuis 2010, mais elle n’a été identifiée qu’en juillet 2026. Elle permettait à une machine virtuelle disposant des droits d’administrateur (root) de compromettre ou de faire planter le serveur physique qui l’héberge. KVM est un composant essentiel de Linux, utilisé par des millions de serveurs dans le monde, ce qui rend cette faille particulièrement dangereuse. La découverte de Januscape a nécessité une réaction urgente pour éviter des cyberattaques massives.

OVHcloud, premier fournisseur de cloud européen, a dû gérer un parc de dizaines de milliers d’hôtes hébergeant environ un million de machines virtuelles réparties dans ses datacenters à travers le monde. Chaque hôte est un serveur physique qui exécute plusieurs machines virtuelles. La faille Januscape menaçait donc directement l’intégrité de ces serveurs, ce qui a poussé OVHcloud à agir rapidement. Le groupe a dû trouver une solution pour corriger cette faille sur l’ensemble de son infrastructure sans interrompre le service pour ses clients, une tâche complexe à l’échelle d’un million de machines virtuelles.

Face à l’urgence, OVHcloud a examiné plusieurs solutions pour corriger la faille. La première consistait à attendre la publication d’un correctif officiel par les mainteneurs de Linux, mais cette option était trop lente. Une autre solution, appliquer un patch à chaud (sans redémarrer les serveurs), a été jugée trop risquée. OVHcloud a également envisagé de désactiver la virtualisation imbriquée (une technique permettant d’exécuter des machines virtuelles dans d’autres machines virtuelles) ou de migrer les machines virtuelles vers des hôtes déjà corrigés. Toutes ces options ont été abandonnées car elles étaient soit inefficaces, soit trop complexes à mettre en œuvre à grande échelle. L’entreprise a donc choisi une approche plus radicale : intégrer elle-même le correctif dans sa version de Linux et redémarrer tous les hôtes concernés.

La campagne de correction a débuté le 8 juillet 2026, avec une phase de test à Sydney, choisie pour la taille réduite de son parc. L’opération s’est ensuite propagée région par région, en suivant le fuseau horaire pour éviter les perturbations en pleine journée. OVHcloud a mis en place des seuils d’arrêt automatique : si 15 hôtes tombaient en panne simultanément dans les zones denses ou 5 ailleurs, l’opération était suspendue. L’entreprise a également calculé des graphes de colocalisation pour éviter de redémarrer deux hôtes portant des instances d’un même client en même temps. Cette stratégie a permis de limiter les pannes et de garantir une correction progressive de l’ensemble du parc.

Malgré une préparation minutieuse, la campagne de correction a connu plusieurs incidents techniques. Par exemple, certaines machines virtuelles n’ont pas redémarré en raison d’un conflit entre deux services internes. D’autres ont subi des corruptions de données à cause d’écritures disque interrompues brutalement. À Paris, un blocage mutuel de deux briques logicielles de gestion du cloud a paralysé le système pendant deux heures. Julien Levrard, le CISO d’OVHcloud, a qualifié ces problèmes de « marginaux » au regard de l’ampleur de l’opération. Il a souligné que le nombre de pannes était « raisonnable » compte tenu du volume de machines virtuelles corrigées.