OVHcloud a confirmé qu’un attaquant a substitué les binaires publiés de cinq versions de son outil en ligne de commande, OVHcloud CLI, par d’autres conçus pour dérober les secrets stockés sur le disque du système exécutant l’outil. L’incident s’est produit le lundi 19/10/2026 et concerne les versions v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 téléchargées depuis GitHub. Toute personne ayant installé ou mis à jour cet outil à cette date doit le supprimer, installer la version v0.16.0 et changer toutes les informations sensibles présentes sur son système.

Résumé en 20 secondes de l’attaque contre le CLI d’OVHcloud

• Versions compromises : de la v0.11.0 à la v0.15.0. La v0.10.0 et la v0.16.0 sont saines, selon OVHcloud.
• Les fichiers malicieux ont été publiés entre 14h47 et 16h21, heure métropolitaine.
• L’attaquant a utilisé le compte GitHub d’un développeur.
• Si cela vous concerne, changez tous vos secrets de système.

L’annonce a été faite par le fondateur d’OVHcloud, Octave Klaba, sur le réseau social X. Un détail important : « 14h47 » n’est pas un numéro de version mais l’heure à laquelle la version modifiée a été diffusée. OVHcloud l’a détectée et bloquée à 16h21, après qu’un client ait signalé le problème. Une première vérification n’a pas révélé d’autres dépôts affectés.

Ce qui s’est passé sur le dépôt GitHub

Selon Klaba, l’attaquant a utilisé le compte GitHub d’un des développeurs du projet pour ajouter un binaire « conçu pour récupérer des secrets depuis le disque ». Klaba précise que « la qualité de ce binaire est faible, mais il peut aller jusqu’au bout ». La société continue d’analyser le code malveillant et prévoit de publier plus de détails ultérieurement.

Une analyse par The Hacker News et des chercheurs d’OpenSourceMalware apporte du contexte. L’attaquant n’a pas modifié le code source, ni les étiquettes, ni la chaîne d’intégration continue : il a supprimé et ré-uploadé, avec le même nom, des fichiers de version déjà publiée, compilés par ses soins. Il a pu faire cela car le dépôt ne verrouillait pas l’inviolabilité des versions de GitHub, une option qui empêche de modifier une version après sa publication. Klaba a reconnu que cette option était désactivée à l’origine, mais OVHcloud la a désormais activée.

Dans la version v0.15.0, les paquets pour macOS (Intel et Apple Silicon), Linux (x86_64 et ARM64) ainsi que Windows x86_64 ont été remplacés, de même que le fichier checksums.txt, qui a été modifié pour faire correspondre les sommes de contrôle aux binaires malicieux. C’est un processus d’intégration continue d’un client, qui avait fixé le hash initial et détecté la modification, qui a permis de repérer l’altération et de lancer une alerte publique. On ignore comment les identifiants du développeur ont été dérobés. OpenSourceMalware relie l’incident à la campagne GlassWorm, mais il s’agit d’une hypothèse personnelle non confirmée.

Qui est concerné et que faire ?

Le risque concerne toute personne ayant téléchargé manuellement ou via script l’un de ces binaires depuis GitHub durant la fenêtre d’attaque, ou ayant mis à jour l’outil avec sa propre commande durant cette période. Selon The Hacker News, ceux qui ont utilisé Homebrew, qui fixe les hashes initiaux, ou ceux qui ont compilé depuis le code source ou utilisé l’image Docker ne sont pas concernés. OVHcloud n’a pas précisé combien de copies ont été téléchargées.

L’outil stocke les secrets de l’API OVHcloud dans le fichier ~/.ovh.conf et les lit également depuis des variables d’environnement. Il faut donc commencer par changer ces secrets en priorité. La recommandation d’OVHcloud va plus loin : il faut changer tous les secrets du disque, y compris les clés SSH, tokens de fournisseurs de cloud, identifiants Git, et mots de passe stockés dans des fichiers de configuration. Voici les étapes recommandées :

1. Supprimer le binaire compromis, puis installer la version 0.16.0, publiée comme version immuable.
2. Changer les identifiants depuis un autre ordinateur, pas depuis celui où le binaire a été exécuté.
3. Révoquer puis régénérer les clés de l’API OVHcloud et tous les autres secrets du système.
4. Vérifier les téléchargements et fixer les hashes dans les scripts et l’intégration continue.

Pour confirmer qu’un fichier téléchargé correspond bien à la version officielle, GitHub offre un outil en ligne de commande :

gh release verify-asset v0.16.0 NOM_DU_FICHIER --repo ovh/ovhcloud-cli

Ce cas survient peu après que certaines copies de Rank Math SEO PRO 3.0.123 aient été distribuées avec du malware, un autre incident ayant aussi concerné les canaux officiels de téléchargement. Dans le cas d’OVHcloud, il ne s’agit pas d’une faille technique exotique : il suffisait d’un compte compromis avec des droits d’écriture et d’une configuration GitHub non sécurisée. Cette fois, c’est une outil destiné à gérer serveurs et identifiants cloud qui a été ciblée.

Questions fréquentes

Quelles versions d’OVHcloud CLI sont compromises ?

Les versions v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 téléchargées depuis GitHub le 19/10/2026. OVHcloud précise que la v0.10.0 et la v0.16.0 sont saines.

La version 14h47 d’OVHcloud CLI existe-t-elle ?

Non. 14h47 indique l’heure à laquelle la version compromise a été publiée, ce n’est pas un numéro de version. OVHcloud l’a bloquée à 16h21.

Suis-je concerné si j’ai utilisé Homebrew ou Docker pour installer OVHcloud CLI ?

Selon The Hacker News, non : Homebrew fixait déjà les hashes d’origine, et l’image Docker n’a pas été modifiée. De même, les compilations depuis le code source n’ont pas été affectées.

Que faire si j’ai lancé une version compromise ?

Supprimez le binaire, installez la version 0.16.0 et, depuis un autre système, changez tous les secrets présents sur cette machine, notamment les identifiants de l’API OVHcloud.

Sources :