OVHcloud : les binaires officiels de son outil CLI remplacés sur GitHub par un voleur de secrets pendant 1 h 33

Le 19 octobre 2026, le compte GitHub compromis d’un développeur d’OVHcloud a servi à remplacer les fichiers des versions v0.11.0 à v0.15.0 d’ovhcloud-cli par une version piégée qui dérobe clés SSH et identifiants cloud. Environ 250 téléchargements ont eu lieu avant le retrait : quiconque a installé l’outil pendant ce créneau doit renouveler ses secrets.

Ce qui s’est passé

Le 19 octobre 2026, entre 14 h 47 et 16 h 21, les binaires officiels d’ovhcloud-cli, l’outil en ligne de commande qui sert à piloter comptes et services OVHcloud, ont été remplacés sur GitHub par des copies malveillantes. D’après l’avis de sécurité publié par OVHcloud, le compte GitHub compromis d’un de ses développeurs a permis d’écraser les fichiers des versions v0.11.0 à v0.15.0 pour macOS, Linux et Windows. C’est un client qui a donné l’alerte à 15 h 50 : son intégration continue vérifie l’empreinte des fichiers téléchargés et s’est mise à échouer. Les fichiers ont été supprimés à 16 h 21, puis une v0.16.0 saine, signée et immuable a été publiée à 19 h 16. OVHcloud recense environ 250 téléchargements sur la période.

Comment les attaquants sont entrés

Selon l’hébergeur, l’ordinateur personnel du développeur avait été infecté un an plus tôt, le 20 octobre 2025, par une extension d’éditeur de code piégée liée au groupe Glassworm ; les clés volées à l’époque ont servi à déposer les fichiers. Le dépôt n’imposait pas l’immuabilité des publications, si bien que des fichiers déjà publiés pouvaient être écrasés. Le code source, la chaîne de compilation et l’intégration continue interne d’OVHcloud ne sont pas touchés, assure l’entreprise. La version piégée fonctionne normalement mais récupère clés SSH, identifiants AWS, Google Cloud et Azure, configurations Docker et Kubernetes, jetons npm, Terraform et DigitalOcean, le fichier .netrc, la configuration Git ainsi que des données d’éditeurs de code et d’assistants d’IA, avant d’envoyer le tout vers un serveur distant.

Que faire maintenant

  1. Vérifiez si l’outil a été téléchargé le 19 octobre entre 14 h 47 et 16 h 21, sur les postes, les runners d’intégration continue comme sur les serveurs.
  2. N’exécutez pas le binaire : calculez son empreinte avec md5sum et comparez-la aux cinq empreintes MD5 publiées dans l’avis.
  3. Cherchez la trace du maliciel : un dossier envchecker- suivi de chiffres dans le répertoire temporaire (ls -d /tmp/envchecker-*, ou sous $TMPDIR sur macOS).
  4. En cas d’exposition : considérez tous les secrets de la machine comme compromis, révoquez et remplacez clés SSH, clés cloud, fichiers kubeconfig, jetons de registre et npm, et par précaution vos clés d’API OVHcloud ; bloquez 45.32.148.174 et passez en revue les journaux de vos comptes cloud.
  5. Réinstallez la version v0.16.0 ou ultérieure.

Notre avis

Un outil d’administration installé sur un poste ou un runner détient les clés de toute l’infrastructure. Vérifiez systématiquement l’empreinte des binaires que vous téléchargez, comme l’a fait le client à l’origine de l’alerte, bannissez les secrets permanents stockés en clair et gardez un œil sur les extensions installées par vos développeurs.

Sources

Comment nous choisissons, vérifions et rédigeons nos analyses →

La porte d’entrée était un tiers. Vérifiez ce que vos fournisseurs exposent publiquement — sans intrusion, uniquement des informations publiques :

Tester un fournisseur Tester un serveur

Vous craignez que vos serveurs soient exposés ? Notre équipe audite, corrige et surveille vos infrastructures Linux et cloud 24h/24, 7j/7.

Parler à un expert Notre offre d’infogérance de serveurs →