La faille Januscape a contraint OVHcloud à corriger et redémarrer, en onze jours, un parc d’environ un million de machines virtuelles. Le 20 juillet 2026, le responsable de la sécurité de l’hébergeur, M. Julien Levrard, a publié un retour d’expérience détaillé sur cette opération.
La vulnérabilité, référencée CVE-2026-53359, avait été divulguée le 6 juillet. Ce récit intéresse tout DPO dont les données tournent chez un hébergeur : il montre l’obligation de sécurité au moment où elle percute la continuité de service.
Une faille de seize ans au cœur de la virtualisation
Le chercheur Hyunwoo Kim a découvert Januscape dans le cadre de kvmCTF, le programme de récompense de Google. Il s’agit d’une vulnérabilité de type « use-after-free », présente depuis seize ans dans KVM, le moteur de virtualisation intégré au noyau Linux. Elle permet à une machine virtuelle malveillante de faire planter le serveur physique qui l’héberge, voire d’en prendre le contrôle.
Selon le chercheur, cité par SecurityWeek, il s’agit de la première faille d’évasion de KVM exploitable sur les processeurs Intel comme AMD. Or KVM fait tourner une large part des serveurs privés virtuels et des instances cloud.
Chez OVHcloud, le périmètre comptait des dizaines de milliers de serveurs hôtes et environ un million de machines virtuelles. En interne, un test reproduisait le plantage d’un serveur non corrigé en deux minutes environ.
Onze jours de crise et un choix assumé
OVHcloud redoutait la publication d’un code d’exploitation permettant de prendre le contrôle des serveurs hôtes. Un tel code aurait menacé directement la confidentialité des données des clients. L’hébergeur a donc retenu un « patching unilatéral à impact contrôlé » : corriger et redémarrer tout le parc sans attendre l’accord de chaque client.
L’opération a avancé en continu, de Sydney vers l’Europe puis l’Amérique du Nord. Elle reposait sur des garde-fous précis. D’abord, des seuils d’arrêt en cas de pannes multiples. Ensuite, la migration à chaud des charges sensibles, comme les bases de données. Enfin, des graphes de co-localisation, calculés pour ne jamais redémarrer en même temps deux serveurs portant les instances d’un même client.
Des incidents ont tout de même émaillé la campagne : machines virtuelles qui ne redémarraient pas, corruption de données sur des machines virtuelles réparties sur trois clusters, saturation du support au Canada. OVHcloud attribue cette corruption à un redémarrage forcé en pleine écriture sur disque, cause qu’il juge la plus vraisemblable. L’hébergeur a donc porté à 60 secondes le délai d’arrêt propre avant l’arrêt forcé. Au onzième jour, la totalité du parc était corrigée.
Nous jugeons ce choix fondé. Attendre l’accord de chaque client laissait ouverte une faille capable d’exposer les données de tous. Le prix payé, quelques redémarrages subis et des incidents localisés, reste inférieur au risque évité.
Faille Januscape : ce que le RGPD attend de l’hébergeur et du client
L’article 32 du règlement général sur la protection des données (RGPD) impose au responsable de traitement comme au sous-traitant des moyens garantissant la confidentialité, l’intégrité, la disponibilité et la résilience des systèmes. Corriger vite une vulnérabilité critique relève pleinement de cette obligation, quitte à sacrifier un peu de disponibilité.
Si la faille avait servi à accéder aux données hébergées, les articles 33 et 34 auraient pris le relais. L’hébergeur, sous-traitant, doit alors prévenir ses clients dans les meilleurs délais. Le client, responsable de traitement, notifie ensuite la Commission nationale de l’informatique et des libertés (CNIL), si possible sous 72 heures, puis informe les personnes en cas de risque élevé.
Une violation ne se limite pas à une fuite. L’article 4 du RGPD y inclut en effet la destruction, la perte et l’altération de données, même accidentelles. Ainsi, une base de données personnelles corrompue par un redémarrage constitue une violation, même sans aucune fuite. Inscrivez-la donc au registre des violations, puis évaluez le risque pour décider d’une éventuelle notification. Par ailleurs, l’article 32 exige de pouvoir rétablir la disponibilité des données dans des délais appropriés et de tester régulièrement l’efficacité des mesures.
Cette chaîne suppose un contrat clair. Vérifiez que le vôtre prévoit les délais d’alerte et les maintenances de sécurité d’urgence, en vous aidant de notre article Sous-traitant RGPD : obligations et contrat type DPA.
Faille KVM et NIS 2 : la gestion des vulnérabilités devient la norme
En tant que fournisseur de services d’informatique en nuage, OVHcloud entre dans le champ de la directive NIS 2. Celle-ci exige des entités essentielles et importantes une politique de traitement des vulnérabilités et de gestion des incidents.
L’épisode illustre la logique du texte : anticiper, corriger vite, documenter, puis partager le retour d’expérience. Pour vos propres serveurs Linux, la même exigence de rapidité s’applique, comme nous l’expliquions dans Failles Linux et agents IA de sécurité : le RGPD vous oblige à corriger plus vite.
Les vérifications à faire chez vos hébergeurs
Le retour d’expérience d’OVHcloud contient un détail qui vous concerne directement : des notifications ne sont pas parvenues à leurs destinataires, notamment faute d’adresses de contact à jour. Une alerte de sécurité qui tombe dans une boîte abandonnée ne protège personne.
- Mettez à jour les coordonnées de contact technique et sécurité chez chacun de vos hébergeurs.
- Inscrivez vos dépendances cloud dans votre registre et dans vos analyses de risques.
- Ajoutez le scénario « redémarrage forcé par l’hébergeur » à votre plan de continuité d’activité.
- Répartissez vos instances critiques sur plusieurs zones de disponibilité.
- Testez la restauration de vos sauvegardes après une interruption imposée.
- Relisez vos contrats de sous-traitance pour y trouver une clause sur les maintenances de sécurité d’urgence.
Pour évaluer un hébergeur avant de signer, appuyez-vous sur Cloud souverain : les 7 preuves à exiger d’un hébergeur. DPO Suite, l’application de conformité de DPO PARTAGE, suit vos sous-traitants et leurs engagements dans le même registre.
Sources
Le déroulé de la campagne, les chiffres du parc et les incidents proviennent du blog d’OVHcloud, CVE-2026-53359 (Januscape) patch campaign: Lessons learned from handling a KVM flaw on tens of thousands of machines.
La découverte par Hyunwoo Kim et la portée Intel et AMD sont décrites par SecurityWeek dans Linux Kernel Vulnerability Allows VM Escape on Intel and AMD Systems.
La presse française a également couvert l’affaire, avec Le Monde Informatique dans Une vieille faille dans l’hyperviseur KVM menace les serveurs Linux et Next dans Suite à la faille KVM, OVHcloud fait le bilan de sa migration monstre.
Les articles 4 et 32 du RGPD et la directive NIS 2 se lisent sur EUR-Lex, Règlement (UE) 2016/679 et Directive (UE) 2022/2555.
