Face à la vulnérabilité critique Januscape, nichée depuis 16 ans dans le noyau Linux, l'hébergeur français a dû patcher des dizaines de milliers de serveurs hébergeant un million de machines virtuelles. Son RSSI, Julien Levrard, a raconté les détails d'une opération de 11 jours : un redémarrage forcé, une stratégie « follow-the-sun » et des incidents assumés pour une sécurité maximale.
Début juillet, une vulnérabilité majeure baptisée Januscape (CVE-2026-53359) a secoué le monde de la virtualisation. Cette faille critique permettait à un attaquant de s'échapper d'une machine virtuelle pour compromettre le serveur physique l'hébergeant, un scénario catastrophe pour tout acteur du cloud. Pour OVHcloud, le risque était immense, menaçant des dizaines de milliers d'hôtes et près d'un million de machines virtuelles clientes à travers le monde.Pourquoi un redémarrage forcé et sans préavis a-t-il été décidé ?
Confrontées à cette menace, les équipes de l'hébergeur ont rapidement évalué leurs options. Appliquer un correctif à chaud semblait trop risqué à grande échelle, et la migration à chaud des machines virtuelles vers des hôtes déjà sécurisés aurait pris des mois, laissant le parc exposé trop longtemps. La seule solution viable, bien que radicale, fut d'intégrer le correctif directement et de redémarrer la totalité des serveurs concernés pour contrer cette faille de sécurité.
La décision la plus audacieuse fut de procéder à un « patching unilatéral à impact contrôlé ». En clair, pas de fenêtre de maintenance négociée avec chaque client, mais des redémarrages imposés pour agir au plus vite. Le comité exécutif a validé cette approche pour protéger le plus grand nombre, acceptant un impact inévitable pour une minorité afin de sécuriser l'infrastructure avant que des attaques ne soient lancées.Comment s'est déroulée cette opération à l'échelle mondiale ?
L'opération a débuté à Sydney, une région de taille modeste choisie comme terrain de test pour éprouver la procédure en conditions réelles. Le correctif a été appliqué sur la version du noyau Linux utilisée par l'entreprise, puis une stratégie « follow-the-sun » (FTS) a été enclenchée : chaque région prenait le relais chaque matin, assurant ainsi une intervention continue sur 11 jours à travers l'Europe et l'Amérique du Nord.
Pour limiter les dégâts, des garde-fous stricts ont été mis en place. Des seuils d'arrêt automatique suspendaient la vague si trop d'hôtes tombaient en panne simultanément. Surtout, des graphes de colocalisation ont été calculés pour ne jamais redémarrer simultanément deux serveurs hébergeant des machines d'un même projet client, préservant ainsi leur haute disponibilité en appliquant au mieux une règle d'« anti-affinité ».
Quels ont été les impacts et les leçons apprises ?Malgré les précautions, l'opération n'a pas été sans heurts, nécessitant un patching à très grande échelle. Des machines virtuelles n'ont pas redémarré seules, victimes de conflits logiciels ou de pannes matérielles comme des barrettes mémoire défaillantes. Des corruptions de données ont été constatées sur trois clusters, et les API de la région parisienne sont restées bloquées pendant deux heures, retardant une vague de mises à jour.
La communication a été volontairement limitée pendant l'opération pour ne pas exposer la séquence de déploiement et inciter des acteurs malveillants à tester l'exploit. Julien Levrard, le RSSI, qualifie l'intervention d'« exploit » technique mais reconnaît les marges de progrès, notamment sur l'information client. Il prévient que l'exercice se répétera et conclut : « Nous devrons faire mieux la prochaine fois ».
merci à GNT
