OVHcloud CLI piégé sur GitHub : que vérifier en PME

Le 19 octobre 2026, entre 14 h 47 et 16 h 21 (heure de Paris), des versions piégées du client en ligne de commande d'OVHcloud ont été téléchargeables sur GitHub. Le binaire malveillant était conçu pour récupérer des secrets stockés sur le disque de la machine qui l'exécute, d'après le fondateur Octave Klaba, cité par Next. L'éditeur, dont le siège est à Roubaix, dit avoir détecté et bloqué l'attaque en un peu moins de deux heures. Pour une PME des Hauts-de-France qui gère ses serveurs chez OVHcloud, le réflexe du jour est simple : vérifier la version installée et, en cas de doute, renouveler ses clés.

L'essentiel au 20 octobre 2026

Versions touchées : v0.11.0 à v0.15.0 du client ovhcloud-cli. Les versions v0.10.0 et v0.16.0 sont indiquées saines (Presse-citron, d'après Octave Klaba).
Fenêtre d'exposition : de 14 h 47 à 16 h 21 le 19 octobre, soit environ 94 minutes (IT-Connect).
Cause déclarée : l'option d'immutabilité des « releases » GitHub n'était pas activée ; un compte développeur détourné a pu modifier des versions déjà publiées sans passer par la chaîne de contrôle d'OVHcloud.
À faire si vous avez installé le client ce jour-là : supprimer le binaire, passer à la v0.16.0, révoquer les clés API OVHcloud et renouveler les autres secrets présents sur la machine.
Ce qu'on ne sait pas : le nombre de téléchargements, la destination des données volées (si elles l'ont été) et l'origine du détournement du compte.

Ce qui s'est passé le 19 octobre, heure par heure

D'après Next et IT-Connect, des fichiers du dépôt officiel du client en ligne de commande d'OVHcloud ont été remplacés par une version modifiée, publiée avec le compte GitHub d'un développeur. L'alerte est venue d'un utilisateur : dans le ticket n° 300, il signale une erreur dans son pipeline d'intégration continue, qui vérifiait la somme de contrôle de l'archive Linux ARM. Octave Klaba a ensuite publié l'analyse de la cause sur X, vers 22 h 30 d'après Next.

Heure (Paris, 19/10)	Événement	Source
14 h 47	Version compromise publiée, selon Octave Klaba	IT-Connect, Presse-citron
Vers 15 h 12	Archives remplacées en place d'après l'analyse d'un utilisateur (v0.13.0 à v0.15.0 citées)	IT-Connect, à confirmer
16 h 21	Problème identifié et bloqué ; binaires malveillants retirés	Next, IT-Connect
Fin de journée	Sortie de la v0.16.0, présentée comme immutable et signée	Next, GitHub
Vers 22 h 30	Analyse de la cause publiée par Octave Klaba ; incident déclaré clos	Next

Les horaires viennent des déclarations d'OVHcloud relayées par la presse. OVHcloud n'a pas, dans les sources lues, communiqué le nombre de téléchargements.

Les chercheurs d'OpenSourceMalware précisent que cinq versions publiées (de la v0.11.0 à la v0.15.0) ont eu leurs binaires remplacés via l'interface de publication de GitHub, sans qu'aucun tag ne soit poussé ni qu'un processus de publication ne s'exécute. Autrement dit, la chaîne d'intégration continue d'OVHcloud, avec ses tests et sa détection de vulnérabilités, n'a jamais été sollicitée. C'est ce que dit aussi Octave Klaba : les contrôles automatisés n'ont pas été touchés, ils ont été contournés. Les plateformes visées sont les plus courantes : Linux (x86_64 et arm64), macOS (x86_64 et arm64) et Windows (x86_64), ainsi que le fichier de sommes de contrôle, lui aussi réécrit.

Pourquoi la vérification de la somme de contrôle n'a rien vu

Le détail est instructif pour toute équipe technique. Le fichier checksums.txt était hébergé au même endroit que les binaires, et il a été remplacé en même temps. Comparer une archive téléchargée avec ce fichier aurait donc donné un faux « tout est conforme ». Selon IT-Connect, seule une empreinte relevée avant l'attaque a permis de remarquer le changement, ce qu'a fait le pipeline de l'utilisateur à l'origine du ticket. OpenSourceMalware relève aussi que le binaire n'a pas été produit par un processus de publication : il a été compilé sur un poste de travail, avec des modifications non enregistrées, à partir d'un commit daté du 13 octobre 2026. Ce sont des indices techniques, pas une preuve de l'identité de l'auteur.

Ce qui est établi, ce qui est supposé

Établi (données serveur GitHub, OpenSourceMalware) : les binaires de cinq versions ont été remplacés le 19 octobre via le compte d'un contributeur ; aucun processus de publication n'a tourné.
Déclaré par OVHcloud : le binaire cherche des secrets sur le disque ; aucun autre dépôt n'est touché ; la cause est l'absence d'immutabilité des releases.
Supposé : l'attribution au groupe GlassWorm repose sur un portefeuille Solana et des techniques communes, pas sur une observation directe. Les chercheurs eux-mêmes notent que rien ne prouve que les actions de mars 2026 sur des dépôts personnels du développeur et le remplacement des binaires soient le fait de la même personne.
Non établi : la destination des données collectées, et si une exfiltration a réellement eu lieu. Le binaire a été supprimé avant d'être analysé.

Qui est concerné parmi les PME des Hauts-de-France ?

OVHcloud a son siège à Roubaix, au 2 rue Kellermann, et la plupart de ses centres de données français sont dans la région, d'après un portrait du Journal du Net (mai 2022). Beaucoup d'entreprises locales y hébergent un site, une messagerie ou des serveurs. Mais être client d'OVHcloud ne signifie pas être concerné : l'incident ne touche que les personnes qui ont téléchargé et exécuté ce client en ligne de commande depuis GitHub, ou via son script d'installation, durant la fenêtre d'exposition. En pratique, cela vise surtout les administrateurs système, les développeurs, les prestataires d'infogérance et les agences web qui pilotent des serveurs, du stockage ou des clés API depuis un terminal ou un pipeline. Les installations par go install ou par compilation depuis les sources ne sont pas concernées, d'après IT-Connect, car le tag de la v0.15.0 n'a pas été modifié. L'image Docker officielle ne l'est pas non plus, selon OpenSourceMalware. Le cas de la commande de mise à jour intégrée est jugé « en principe » concerné par IT-Connect. Nous n'avons trouvé aucune donnée sur le nombre d'entreprises ou de prestataires des Hauts-de-France qui utilisent ce client, et nous n'en inventons pas. Si vous confiez votre hébergement à un prestataire, la question à lui poser est précise : un de vos postes ou de vos pipelines a-t-il installé ce client le 19 octobre, et quelles clés ont été renouvelées ?

Vidéo du CLUSIF : « Supply Chain : comment sécuriser sa chaîne d'approvisionnement ? Le Clusif reçoit l'ANSSI ». Ressource générale sur les attaques par la chaîne d'approvisionnement ; contenu non visionné en intégralité et antérieur à cet incident.

Que faire aujourd'hui : sept vérifications

Vérifier la version installée : la commande ovhcloud version indique la version (Presse-citron). Si elle est comprise entre v0.11.0 et v0.15.0, supprimez le binaire.
Réinstaller par un canal officiel : la version v0.16.0 est présentée comme immutable et signée. Vérifiez son attestation avec l'outil GitHub en ligne de commande, comme le recommande IT-Connect.
Révoquer et recréer les clés API OVHcloud depuis l'espace client, surtout si elles se trouvent dans .ovh.conf ou dans des variables d'environnement.
Renouveler les autres secrets de la machine : clés SSH, jetons GitHub et de registres de paquets, identifiants d'autres clouds, fichiers .env, configurations Kubernetes, mots de passe en clair dans des fichiers de configuration.
Traiter les pipelines comme des postes : si le client a tourné dans une chaîne d'intégration continue, renouvelez les secrets de ce serveur de build.
Consigner une empreinte de référence de chaque binaire tiers que vous déployez, hors du dépôt où il est publié, et comparez avant chaque mise en production.
Protéger vos propres dépôts : activez l'authentification forte sur les comptes GitHub et l'immutabilité des releases (voir ci-dessous).

La leçon pour vos propres dépôts : l'immutabilité des releases

Selon la documentation de GitHub, une « release » immutable verrouille ses fichiers et son tag : ils ne peuvent plus être modifiés ni supprimés après publication, et une attestation vérifiable est générée. Le titre et les notes de version restent modifiables. C'est précisément l'option qu'OVHcloud dit ne pas avoir activée. Pour l'activer, le guide GitHub indique de passer par les paramètres du dépôt (section « Releases », option « Enable release immutability ») ou, pour une organisation, par les paramètres généraux des dépôts. Attention : elle ne s'applique qu'aux releases créées après son activation. Les anciennes versions restent modifiables. GitHub recommande de créer la release en brouillon, d'y joindre tous les fichiers, puis de la publier en dernier. Cet épisode s'ajoute à d'autres alertes récentes sur la chaîne logicielle que nous avons traitées : la faille Metabase et l'ANSSI, le Patch Tuesday d'octobre 2026 et la cyberattaque sur les groupes froid des supermarchés. Sur le sujet de l'hébergeur lui-même, voir aussi SecNumCloud 3.2 et OVHcloud Roubaix.

Vidéo de ZDNet France : « Attaques sur la supply chain : le coup de poignard dans le dos ». Ressource pédagogique générale sur ce type d'attaque ; contenu non visionné en intégralité et antérieur à cet incident.

Ce qu'on ne sait pas encore

Le nombre de téléchargements des versions piégées : OVHcloud ne l'a pas communiqué dans les sources lues.
Le comportement exact du binaire et la destination des données : le binaire a été retiré avant analyse publique ; aucune exfiltration n'est confirmée.
Comment le compte du développeur a été pris : OpenSourceMalware demande que l'analyse d'OVHcloud précise l'accès initial et la durée de présence de l'attaquant.
La réalité de l'attribution à GlassWorm : hypothèse d'un chercheur, non confirmée par OVHcloud.
L'impact local : aucune donnée sur les entreprises des Hauts-de-France touchées.

Nous mettrons cet article à jour si OVHcloud publie son analyse détaillée ou des indicateurs de compromission. Sources consultées le mardi 20 octobre 2026.

FAQ : compromission du client en ligne de commande d'OVHcloud

Mes serveurs et sites hébergés chez OVHcloud ont-ils été piratés ?

Rien dans les sources lues ne l'indique. Il s'agit d'un outil d'administration distribué sur GitHub, pas d'une intrusion dans l'infrastructure. Octave Klaba affirme qu'aucun autre dépôt n'est touché et que les chaînes d'intégration continue n'ont pas été affectées. Seuls ceux qui ont exécuté une version piégée du client sont exposés.

Comment savoir si je suis concerné ?

Vous l'êtes si vous avez téléchargé et exécuté le client en ligne de commande d'OVHcloud (versions v0.11.0 à v0.15.0) le 19 octobre 2026 entre 14 h 47 et 16 h 21, y compris via le script d'installation. Lancez la commande ovhcloud version pour connaître votre version et consultez l'historique de vos téléchargements ou de vos pipelines.

Que dois-je renouveler en priorité ?

Les clés API OVHcloud (fichier .ovh.conf ou variables d'environnement), puis les clés SSH, les jetons GitHub et de registres de paquets, les identifiants d'autres clouds et le contenu des fichiers .env présents sur la machine. Si le client a tourné dans un pipeline, renouvelez aussi les secrets de ce pipeline.

Pourquoi la vérification de la somme de contrôle n'a-t-elle pas protégé ?

Parce que le fichier de sommes de contrôle était publié au même endroit que les binaires et a été remplacé en même temps. Pour qu'une vérification serve, l'empreinte de référence doit venir d'ailleurs ou avoir été relevée avant l'attaque, ou il faut vérifier l'attestation d'une release immutable.

Qu'est-ce que l'immutabilité des releases GitHub et faut-il l'activer ?

C'est une option qui verrouille les fichiers et le tag d'une release après sa publication. Elle protège contre le remplacement d'un binaire déjà publié. Elle ne s'applique qu'aux releases créées après son activation. Si vous distribuez des binaires ou des archives depuis GitHub, la documentation de GitHub recommande de l'activer.