Onze jours ont été nécessaires pour boucler l’ensemble du parc.

Dans un article publié le 20 juillet 2026 sur le blog d’OVHcloud, Julien Levrard, CISO de l’entreprise, est revenu sur la campagne de correction menée en urgence après la divulgation de Januscape début juillet.

Cette faille, référencée CVE-2026-53359, était nichée depuis 2010 dans le sous-système de virtualisation KVM, le composant du noyau Linux qui fait tourner les machines virtuelles sur les serveurs. Elle permet à une machine virtuelle disposant des droits root de faire planter, voire de compromettre, le serveur physique qui l’héberge.

Pour OVHcloud, premier fournisseur de cloud européen, le périmètre concerné était colossal : des dizaines de milliers d’hôtes hébergeant environ un million de machines virtuelles, sur l’ensemble des datacenters du groupe.

Les options sur la table pour mitiger le risque. // Source : OVHcloud

Patcher sans attendre l’accord des clients

Face à l’alerte reçue le 7 juillet, Julien Levrard explique que plusieurs options s’offraient à OVHcloud :

• attendre que les correctifs officiels soient publiés,
• appliquer un patch à chaud,
• désactiver la virtualisation imbriquée,
• migrer les VM vers des hôtes déjà corrigés pendant qu’elles tournaient.

Toutes ont été écartées, jugées soit trop lentes, soit trop risquées à l’échelle du parc. « Dès la confirmation de la vulnérabilité, la priorité est de construire une réponse structurée et coordonnée », explique le CISO. L’entreprise a donc choisi d’intégrer elle-même le correctif dans la version de Linux qu’elle utilise sur ses serveurs, puis de redémarrer la totalité des hôtes concernés, sans attendre l’accord individuel de chaque client.

L’opération a démarré le lendemain depuis Sydney, choisie comme terrain de test pour sa taille réduite, avant de se propager région par région, en suivant le fuseau horaire pour toujours opérer en journée quelque part dans le monde, à travers l’Europe puis l’Amérique du Nord. Pour limiter la casse, OVHcloud a mis en place des seuils d’arrêt automatique, l’opération étant suspendue si 15 hôtes tombent en panne simultanément dans les zones denses et 5 ailleurs, et a calculé des graphes de colocalisation pour éviter de redémarrer en même temps deux hôtes portant des instances d’un même client.

Un exploit opérationnel, mais des marges de progrès

Plusieurs incidents techniques ont malgré tout émaillé la campagne : des VM qui ne redémarraient pas à cause d’un conflit entre deux services internes, de la corruption de données sur des écritures disque interrompues en plein vol, ou encore un blocage mutuel de deux briques logicielles de gestion du cloud à Paris pendant deux heures.

Reste que Julien Levrard qualifie le résultat d’« exploit » compte tenu de l’ampleur du chantier, avec un nombre de pannes jugé raisonnable au regard du volume traité. Le dirigeant assume par ailleurs le choix de ne pas avoir communiqué publiquement pendant l’opération, estimant qu’une transparence complète aurait pu inciter certains clients à tester l’exploit avant que l’ensemble du parc ne soit protégé.

Le CISO prévient toutefois que « d’autres publications de vulnérabilité kernel » sont à prévoir dans les mois à venir. Autrement dit, cette procédure d’urgence, inédite par son ampleur, n’est probablement pas la dernière du genre, et OVHcloud dit vouloir mieux anticiper l’impact et l’accompagnement client à l’avenir : « Nous devrons faire mieux la prochaine fois. »