Syspirit 
Imaginez la scène. Mardi 7 juillet 2026, début d’après-midi, une alerte de sécu tombe. Une faille critique dans KVM, le moteur de virtualisation qui fait tourner la quasi-totalité de vos instances. Des dizaines de milliers d’hyperviseurs, environ un million de VM clientes posées dessus. Et un exploit qui crashe un hôte non patché en deux minutes chrono. Vous avez quelques jours pour tout corriger, pas quelques mois.
C’est exactement ce qui est arrivé à OVHcloud, avec la faille Januscape (CVE-2026-53359). Et la bonne nouvelle, c’est qu’ils ont publié un retour d’expérience détaillé sur toute l’opération, signé Julien Levrard, leur CISO.
Ce qui m’intéresse ici, ce n’est pas tant la faille en elle-même. C’est la logistique. Comment on patche une flotte pareille en urgence, à l’échelle mondiale, sans tout casser.
La faille en 30 secondes
Juste ce qu’il faut pour comprendre l’enjeu, sans partir dans les entrailles du noyau.
Januscape, c’est une faille dans KVM, la brique qui isole les VM les unes des autres sur un même serveur physique. En temps normal, chaque VM est enfermée dans sa bulle : elle ne voit ni l’hôte qui l’héberge, ni les VM voisines. Januscape casse cette bulle.
Le principe de l’attaque : un client qui est root sur sa propre VM peut exploiter un bug de gestion mémoire du noyau pour sortir de sa machine et prendre la main sur le serveur physique. Une fois sur l’hôte, il peut le faire planter, ou aller fouiner dans les VM des autres clients qui tournent juste à côté. On appelle ça un guest-to-host escape, et sur de l’hébergement mutualisé, c’est le pire scénario possible.
Le détail technique, un use-after-free dans le shadow-paging de KVM, est bien décrypté ici si le sujet vous intéresse.
Trois détails qui expliquent l’urgence :
- L’exploit est reproductible : un test interne crashait un hôte non patché en environ deux minutes.
- Tous les noyaux Linux x86 antérieurs au commit de correction sont touchés, quelle que soit la distrib.
- Au moment des faits, aucun code d’exploitation permettant la prise de contrôle de l’hôte n’était public. Mais tout le monde savait que ce n’était qu’une question de temps.
La question n’était donc pas de savoir s’il fallait patcher, mais comment le faire à cette échelle, en sachant qu’un impact client nul était tout simplement impossible.
Cinq options sur la table
C’est le passage que je trouve le plus instructif, parce qu’il montre le raisonnement. OVH a listé cinq façons de traiter le problème, et a éliminé les quatre premières une par une :
- Attendre les noyaux patchés officiels. Ça revenait à dépendre du calendrier d’un tiers et à rester exposé pendant une durée non maîtrisée. Écarté vite.
- Live patch (patcher le noyau à chaud). Ça oblige à activer une option qui réduit le durcissement du noyau et limite la détection en cas de compromission. Trop risqué à l’échelle de la flotte, surtout si un exploit de prise de contrôle sortait. Non.
- Désactiver la virtualisation imbriquée (nested). Ça rend l’exploit inopérant, mais ça casse la capacité de live-migration et l’impact sur les usages clients était impossible à évaluer. Écarté.
- Live-migrer les VM vers des hôtes déjà patchés. Nickel pour la continuité de service, aucun impact sur les VM. Sauf que copier un million de VM d’hôte en hôte, c’est une affaire de mois, pas de jours. Gardé uniquement pour quelques VM critiques.
- Backporter le patch dans leurs noyaux Debian et rebooter tous les hôtes. Le choix retenu.
Croquis original tiré du billet d’OVHcloud.
Le point qui mérite qu’on s’y arrête, c’est la décision assumée derrière l’option 5 : le patch unilatéral à impact maîtrisé. OVH a décidé de patcher et rebooter sans attendre l’accord individuel de chaque client, en sachant pertinemment que certains services seraient coupés.
Le raisonnement tient en trois lignes : ne pas patcher expose toute la flotte à une faille critique ; traiter au cas par cas allongerait le calendrier et laisserait la majorité des hôtes vulnérables pendant des semaines ; agir vite et globalement protège le plus grand nombre, même si ça impacte temporairement une minorité.
En tant que client, se faire rebooter sa VM sans avoir rien demandé, ça pique. Mais vu l’alternative, difficile de leur donner tort. La priorité n’était plus d’éviter l’impact, mais de le minimiser, l’étaler et le rendre prévisible.
La mécanique : follow the sun et canary
L’opération a tourné en follow the sun : une cellule de crise active 24h/24, avec rotation par zone géographique. Chaque région prenait le relais pendant sa propre matinée locale et passait le contexte à la suivante. Trois points de synchro par jour pour se caler entre les équipes (NOC, experts, support, sécu).
Sydney a servi de région pilote. Pourquoi ? Peu d’hôtes, donc risque limité, et surtout la fenêtre creuse locale (la nuit à Sydney) tombe pile pendant les heures de bureau en Europe. Parfait pour valider le runbook en conditions réelles, à petite échelle, avant de le dérouler partout. Un canary, tout simplement, mais à l’échelle d’un datacenter entier.
Une fois la procédure stabilisée sur Sydney, le follow the sun s’est enclenché : première vague européenne le soir même, puis région après région.
L’ordre n’était pas uniforme. VPS d’abord, Public Cloud ensuite, parce que l’exposition n’est pas la même : sur du VPS, l’impact par reboot reste contenu, alors qu’une région Public Cloud concentre des milliers de clients et des instances critiques (bases de données, load balancers, files de messages). Pour le Public Cloud, ils ont commencé par les régions les moins denses, puis affiné la granularité sur les grosses.
Les garde-fous qui font la différence
Deux mécanismes valent le détour, transposables à n’importe quelle échelle.
Les stop thresholds. Chaque vague de reboots avait un seuil d’arrêt : si trop d’hôtes étaient down en même temps (15 dans les grosses régions, 5 ailleurs), la vague se mettait en pause. Un cran d’arrêt pour ne pas continuer à rebooter pendant que les techniciens sur place galèrent encore à relever les machines précédentes.
L’anti-affinity. Le vrai risque pour un client, ce n’est pas le reboot, c’est de voir toutes ses instances tomber d’un coup alors qu’il les avait justement réparties pour être résilient. Les orchestrateurs ne rebootaient donc jamais deux hôtes d’un même client en même temps. Du best-effort, pas garanti à 100%, mais de quoi rendre l’impact absorbable côté application.
Les galères, parce qu’il y en a toujours
Ce que j’aime dans ce REX, c’est qu’il n’enjolive rien. OVH a été transparent sur les différents problèmes rencontrés et ce que leur opération a impliqué :
- Des VM qui ne redémarrent pas. Dès la première vague européenne,
libvirt-guestsentrait en conflit avec Nova et coupait des instances sans prévenir l’API. Fix : désactiver et masquer le service avant reboot. - De la corruption de données. Certains reboots forcés sont tombés en plein milieu d’une écriture disque. Fix : allonger la fenêtre d’arrêt propre à 60 secondes avant le kill.
- Du hardware qui lâche. Rebooter des dizaines de milliers de machines, il y a forcément de la casse. La première nuit, 20 à 30 hôtes sur 6000 ne sont pas revenus seuls : barrettes mortes, pile CMOS à retirer, interfaces réseau HS. Des techniciens étaient mobilisés sur chaque site pour tout ce qu’aucun outil ne peut faire à leur place.
Ce dernier point, on l’oublie souvent quand on pense “flotte cloud”. Derrière l’orchestrateur, il y a des gens dans les DC, prêts à intervenir dans une baie à 3h du mat’.
La com pendant la crise
Communiquer largement pendant l’opération posait un dilemme : détailler la séquence de déploiement, c’était donner aux attaquants la carte des hôtes encore vulnérables, et potentiellement pousser des curieux à “tester” l’exploit disponible. OVH a donc fait le choix de la discrétion pendant l’exécution.
Concrètement : pas de status page publique au début, une com ciblée et progressive, envoyée seulement aux clients dont les instances étaient sur des hôtes programmés au reboot, région par région.
Ça n’a pas été parfait, et ils le disent. Pour des grosses régions comme GRA6 (près de 90 000 clients concernés), l’emailing de masse a été écarté pour éviter un raz-de-marée de tickets. Certains messages ne sont jamais arrivés (adresses obsolètes, notifs filtrées). Le pivot : une bannière conditionnelle dans le Manager, via feature flipping, qui s’affiche si le client connecté fait partie des comptes impactés. Développée et déployée en pleine opération.
Conclusion
Ce REX est vraiment intéressant. On y voit la coordination des équipes, le sang-froid et la méthodo qu’il faut dans une boîte qui vend du cloud et de la haute dispo. Et pour eux, c’était une grande première :
Patching and restarting every Public Cloud and VPS host had never been done before under this kind of time pressure.
En 11 jours, franchement, c’est respectable. Ils assument dès le départ qu’il y aura des effets de bord, mais l’objectif n’a jamais été le zéro impact, ils le disent eux-mêmes :
Rebooting a fleet of this global scale with zero impact was not an achievable goal. The objective was therefore the smallest possible impact compatible with the security of the entire fleet.
Ce que je retiens surtout, c’est leur choix d’avancer en toute discrétion. Pas de grosse annonce publique, juste une com ciblée région par région, histoire de ne pas filer aux attaquants la liste des hôtes encore vulnérables. Réussir à patcher une opération de cette taille avec un impact aussi minime, et presque en catimini, je trouve ça assez impressionnant.
Et vu le rythme des failles noyau qui sortent, ils préviennent que ça se reproduira. Ils comptent faire mieux la prochaine fois, notamment sur la communication aux clients en amont.
Sources : le billet d’OVHcloud signé Julien Levrard, repéré via The Register.