~/dev/ovhcloud-cli-binaires-pieges-github

OVHcloud CLI : des binaires piégés sur GitHub pendant 94 minutes pour voler des secrets

dev / / 3 min de lecture / florian

Le 19 octobre, pendant environ 94 minutes, les binaires de la CLI officielle d’OVHcloud (ovhcloud-cli) publiés sur GitHub ont été remplacés par des versions piégées. Les versions 0.11.0 à 0.15.0 embarquaient un module qui vole les secrets présents sur la machine. OVHcloud a publié le 20 octobre un avis de sécurité, GHSA-862f-55f5-vmvw, classé de gravité élevée.

Ce qui s’est passé

D’après l’avis d’OVHcloud, un attaquant a utilisé le compte GitHub compromis d’un développeur ayant les droits d’écriture sur le dépôt. Il a remplacé les fichiers de releases existantes, publiées des semaines plus tôt, par des builds malveillants. Il a aussi réécrit le fichier checksums.txt : vérifier l’empreinte sur la page de release ne servait donc à rien.

L’alerte est venue d’un utilisateur dont la CI épingle l’empreinte SHA-256 de l’archive Linux arm64. Le build a échoué, et il a ouvert le ticket #300 sur le dépôt. Selon son analyse, le binaire de remplacement ne venait pas du tag v0.15.0 : il avait été compilé localement, à partir d’un arbre de travail modifié.

Toujours selon OVHcloud, le MacBook personnel du développeur avait été compromis des mois plus tôt, apparemment par une extension de navigateur ou d’éditeur malveillante installée en octobre 2025, et l’avis relie l’attaque au groupe GlassWorm. Le code source, la chaîne de build interne d’OVHcloud, qui n’est pas hébergée sur GitHub, et les autres dépôts n’ont pas été touchés.

Chronologie (19 octobre, heure de Paris)

HeureÉvénement
14 h 47Premier binaire de la v0.15.0 remplacé (macOS)
14 h 57Tous les binaires de la v0.15.0 remplacés
15 h 30Binaires des versions 0.11.0 à 0.15.0 remplacés
15 h 50Un utilisateur signale une activité suspecte
16 h 21Binaires malveillants supprimés
18 h 52Annonce publique
19 h 16Publication de la v0.16.0, saine, avec tag signé

Ce que vole le malware

  • identifiants AWS, Google Cloud, Azure et DigitalOcean ;
  • clés SSH, configurations Git, Docker et Kubernetes, fichier .netrc ;
  • identifiants Terraform et npm ;
  • bases locales d’éditeurs et d’assistants de code (VS Code, Cursor, Continue, Cody, OpenCode, Claude…).

Les données étaient compressées puis envoyées vers un serveur distant, avec une résolution d’adresse passant par des requêtes RPC Solana. Ne sont concernés que les téléchargements effectués entre 14 h 47 et 16 h 21 : via install.sh, le téléchargement manuel ou la commande de mise à jour intégrée. Selon IT-Connect, go install, la compilation depuis les sources et l’image Docker n’étaient pas touchés.

Vérifier votre poste

L’avis fournit en annexe les empreintes MD5 des binaires malveillants pour chaque plateforme. Calculez celle de votre binaire sans l’exécuter et comparez-la à cette liste, puis cherchez les dossiers temporaires que le malware ne supprime pas :

# Empreinte du binaire, à comparer aux valeurs de l'avis GHSA-862f-55f5-vmvw
md5sum "$(command -v ovhcloud)"      # Linux
md5 "$(command -v ovhcloud)"         # macOS

# Traces laissées par le malware s'il a tourné
ls -d /tmp/envchecker-* 2>/dev/null          # Linux
ls -d "$TMPDIR"/envchecker-* 2>/dev/null     # macOS

Si vous avez exécuté un binaire piégé, considérez tous les secrets de la machine comme compromis : clés d’API OVHcloud, comptes cloud, clés SSH, jetons de registres, kubeconfig et fichiers .env. Révoquez-les, recréez-les, puis supprimez le binaire et installez la v0.16.0.

Ce qui a manqué, et ce qu’OVHcloud change

La cause directe est simple : les releases du dépôt n’étaient pas immuables. N’importe quel compte ayant les droits d’écriture pouvait remplacer un fichier publié. OVHcloud a supprimé les fichiers malveillants, suspendu le compte compromis, activé les releases immuables sur toute son organisation GitHub et prévoit des commits signés, une provenance des builds et le rattachement des publications à son IAM interne.

Pour vos propres outils : activez les releases immuables sur vos dépôts, et côté consommateur, épinglez l’empreinte des binaires que vous téléchargez dans votre CI, comme l’utilisateur qui a donné l’alerte. Une empreinte publiée au même endroit que le binaire ne protège pas d’un attaquant qui peut modifier les deux.

Sources

$ echo "votre commentaire"

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *