OVHcloud CLI compromis : versions touchées et que faire

Le 19 octobre 2026, des fichiers de la CLI officielle d’OVHcloud (dépôt ovh/ovhcloud-cli) ont été remplacés par des binaires piégés, publiés depuis le compte GitHub d’un développeur. Si vous avez téléchargé la CLI ce jour-là, supprimez-la, installez la v0.16.0 et considérez comme exposés tous les secrets lisibles sur la machine.

Octave Klaba, fondateur d’OVHcloud, a annoncé l’incident sur X. J’ai recoupé son message avec l’issue publique ouverte sur le dépôt, la page des releases et la presse spécialisée. Voici ce qui est établi, ce qui reste flou et ce qu’il faut faire.

Table des matières

Ce qui s’est passé

Selon OVHcloud, le binaire compromis a été publié à 14h47 (heure de Paris), puis détecté et bloqué à 16h21 grâce au signalement d’un client. La fenêtre d’exposition annoncée est donc d’environ 94 minutes.

L’issue GitHub #300, ouverte par un utilisateur dont la CI vérifie le SHA-256 des archives, apporte des détails vérifiables. Les fichiers des releases v0.13.0 à v0.15.0 ont été remplacés entre 12h47 et 13h12 UTC (14h47 à 15h12 à Paris), plusieurs semaines après leur publication. L’archive ovhcloud-cli_Linux_arm64.tar.gz et le fichier checksums.txt ont été réécrits, tout comme les archives macOS et Windows de la v0.15.0.

Le point qui compte : le tag Git v0.15.0 pointe toujours vers le même commit et le proxy de modules Go sert le même code. Le code source n’a pas été modifié, seuls les fichiers téléchargeables l’ont été. Relire le code ou vérifier le tag n’aurait rien détecté. Comparer le hash de l’archive, si.

D’après OVHcloud, l’attaquant a utilisé le compte GitHub d’un développeur pour ajouter un binaire chargé de récupérer les secrets présents sur le disque. L’entreprise juge sa qualité médiocre, mais suffisante pour aller au bout de sa tâche. Les premières vérifications n’ont révélé aucun autre dépôt affecté.

Quelles versions sont touchées ?

OVHcloud liste cinq versions compromises, de la v0.11.0 à la v0.15.0. L’issue publique ne documente que les v0.13.0 à v0.15.0 (la v0.15.0 entièrement, les deux autres partiellement). Par prudence, traitez les cinq comme compromises. Les versions v0.10.0 et v0.16.0 sont saines.

Seuls les téléchargements effectués après le remplacement des fichiers, donc le 19 octobre, sont concernés. Une installation faite avant ce jour ne l’est pas, sauf mise à jour ou réinstallation le jour même. OVHcloud n’a pas précisé si Homebrew, l’image Docker ou le script d’installation ont distribué les fichiers piégés : dans le doute, appliquez la même procédure.

D’après l’auteur de l’issue, une installation depuis le proxy de modules Go (go install) servait le code d’origine.

Que faire maintenant ?

1. Identifier si vous êtes concerné

Notez la version installée et la date de téléchargement. Comparez ensuite le hash de l’archive avec la ligne correspondante du fichier checksums.txt de la release, qui a été restauré avec les fichiers d’origine :

sha256sum ovhcloud-cli_Linux_arm64.tar.gz
# à comparer avec checksums.txt de la release correspondante

Pour un binaire déjà installé, les informations de build Go permettent un premier tri. Le binaire analysé dans l’issue indiquait un build « dirty », c’est-à-dire fait depuis un dépôt local modifié :

go version -m "$(command -v ovhcloud)" | grep -E 'dirty|vcs.modified'

L’absence de résultat ne prouve rien. En cas de doute, supprimez et réinstallez. L’auteur de l’issue publie aussi les hashes de l’archive Linux arm64 de la v0.15.0 :

original  5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0
remplacé  3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb

2. Supprimer, puis installer la v0.16.0

Supprimez le binaire, installez la v0.16.0 et vérifiez son hash. Cette release est annoncée comme immutable : GitHub n’autorise plus à modifier ses fichiers après publication.

3. Révoquer, puis réémettre les secrets

Supprimer le binaire ne suffit pas : il a peut-être déjà lu vos fichiers. Considérez comme exposé tout ce que votre utilisateur pouvait lire sur la machine :

les identifiants d’API OVHcloud utilisés par la CLI ;
les clés SSH, les fichiers kubeconfig, les fichiers .env ;
les identifiants AWS, GCP ou Azure, les tokens GitHub, npm ou Docker ;
les secrets exportés dans des variables d’environnement ou des scripts.

Révoquez d’abord, réémettez ensuite, sans période de chevauchement entre l’ancien et le nouveau secret. Pour les clés SSH, notre guide pour sécuriser son serveur SSH détaille la rotation.

4. Auditer les journaux

Regardez l’usage de vos identifiants depuis le 19 octobre 14h47 : appels d’API inhabituels, nouvelles clés, instances ou stockages que vous n’avez pas créés, connexions depuis des adresses inconnues. OVHcloud n’a pas publié le comportement réseau du binaire : aucun domaine ni aucune IP à bloquer n’est connu pour l’instant.

5. Corriger vos pipelines

Si une CI ou un script a téléchargé la CLI ce jour-là, les secrets de ce job sont exposés. Figez la version et le SHA-256 attendu : c’est exactement ce garde-fou qui a permis de repérer l’attaque.

Ce qu’on ne sait pas encore

Le nombre de téléchargements des fichiers piégés.
Les fichiers lus par le binaire et le canal d’exfiltration. OVHcloud promet des détails sur l’analyse du binaire.
Comment le compte du développeur a été compromis, et quels droits il avait sur le dépôt. L’auteur de l’issue a posé la question, sans réponse publique à ce stade.
Le post-mortem, annoncé « dans les prochains jours ».

Un détail pour les vérificateurs : GitHub affiche le tag v0.16.0 comme signé, mais signale que la clé de signature a expiré.

Trivy, tj-actions : un schéma qui se répète

Incident	Vecteur d’entrée	Ce qui a été altéré	Cible du code malveillant
OVHcloud CLI (oct. 2026)	Compte GitHub d’un développeur	Fichiers de releases déjà publiées	Secrets sur le disque des utilisateurs
Trivy / TeamPCP (mars 2026)	Jeton d’accès personnel exposé via un workflow mal configuré	Version v0.69.4 et dizaines de tags d’actions	Secrets des pipelines CI
tj-actions/changed-files (mars 2025)	Jeton d’accès personnel compromis	Tags redirigés vers un code malveillant	Secrets des pipelines CI, affichés dans les journaux

Dans les trois cas, tout part d’un identifiant de mainteneur, et l’attaquant modifie des artefacts que les utilisateurs considéraient comme figés. Selon l’analyse de SafeDep, la version malveillante de Trivy est restée en ligne environ trois heures, une durée du même ordre que les 94 minutes d’OVHcloud : une fenêtre courte suffit quand l’outil s’exécute avec des droits élevés.

La différence est la cible. Trivy et tj-actions visaient les pipelines CI. Ici, le binaire est destiné aux postes des développeurs et des administrateurs, qui concentrent des clés cloud, des clés SSH et des tokens. Une CLI d’infrastructure est une cible de choix : elle s’exécute avec les droits de la personne qui administre le cloud.

Côté mainteneurs : rendre ce scénario impossible

Activer les releases immutables. Depuis octobre 2025, GitHub peut verrouiller le tag et les fichiers d’une release une fois publiée. Remplacer un fichier d’une version existante, comme ici, n’est alors plus possible.
Protéger les tags avec des règles (rulesets) qui interdisent la modification, la suppression et le force push.
Limiter les comptes qui publient : clés de sécurité matérielles ou passkeys, pas de jetons classiques à longue durée de vie, droits de publication séparés des droits de développement.
Publier des attestations de provenance, que les releases immutables génèrent automatiquement, pour que les utilisateurs vérifient l’origine d’un fichier.
Activer le signalement privé des vulnérabilités. L’auteur de l’issue précise n’avoir trouvé aucun canal privé et avoir dû ouvrir une issue publique.

Côté utilisateurs : les bons réflexes

Figer la version et le SHA-256 dans les CI et les scripts, comme l’a fait l’auteur de l’issue.
Éviter les installations non vérifiées, par exemple un script récupéré depuis une branche principale et exécuté directement.
Réduire ce qui traîne sur le disque : identifiants à courte durée de vie, coffre de secrets plutôt que fichiers en clair, gestionnaire de mots de passe.
Isoler les outils tiers dans un bac à sable, comme nous l’expliquons dans notre article sur Docker sbx et Claude Code.
Appliquer les bases de nos 10 mesures essentielles de cybersécurité.

FAQ

Dois-je changer mes secrets si j’utilise la v0.10.0 ?

Non, pas pour cet incident. La v0.10.0 est annoncée saine par OVHcloud. Seuls les téléchargements des v0.11.0 à v0.15.0 le 19 octobre sont concernés.

Désinstaller la CLI suffit-il ?

Non. Le binaire cherchait des secrets sur le disque : s’il a été exécuté, ils ont pu être lus. Supprimez le binaire, puis révoquez et réémettez les secrets.

Le code source de la CLI est-il compromis ?

D’après l’issue, le tag v0.15.0 et le proxy de modules Go servent toujours le code d’origine, et OVHcloud indique qu’aucun autre dépôt n’est affecté. Ce sont les fichiers téléchargeables qui ont été remplacés.

Les services OVHcloud ou les données clients sont-ils touchés ?

À ce stade, OVHcloud n’a communiqué que sur le dépôt de la CLI. Aucune atteinte de son infrastructure ou de données clients n’a été annoncée dans les sources que j’ai consultées.

Sources

Article rédigé le 19 octobre 2026 à partir d’informations encore en cours de publication. Je le mettrai à jour à la sortie du post-mortem d’OVHcloud.

OVHcloud CLI compromis : un binaire voleur de secrets publié sur GitHub