Les versions de l'OVHcloud CLI détournées pour voler des secrets via la compromission d'un compte GitHub

Le lundi 19 octobre, des attaquants ont compromis le compte GitHub d'un contributeur et remplacé les archives de téléchargement de cinq versions existantes de l'interface en ligne de commande OVHcloud. Les binaires malveillants, conçus pour voler des secrets sur les disques locaux, sont restés disponibles sur GitHub pendant 94 minutes avant que le fournisseur cloud ne les retire et ne publie une version propre et immuable.

Ce qui s'est passé

L'incident a visé les versions v0.11.0 à v0.15.0 de l'OVHcloud CLI, publiées entre le 14 avril et le 16 septembre. Entre 12h47 et 14h21 UTC, un attaquant ayant accès au compte du contributeur a supprimé les fichiers d'archive originaux et en a téléversé de nouveaux contenant des logiciels malveillants. L'attaquant a également remplacé le fichier checksums.txt pour garantir que les hachages publiés correspondaient aux binaires malveillants, contournant ainsi les contrôles d'intégrité basiques qui se fient uniquement aux hachages fournis.

Octave Klaba, fondateur d'OVHcloud, a confirmé que le code source, les balises de version (tags) et les pipelines de build internes n'avaient pas été touchés. Les fichiers malveillants étaient de simples builds Go issus d'un commit ultérieur, téléversés directement sur les pages de release GitHub. La société a réagi en supprimant les archives substituées et en publiant la version v0.16.0 comme une release immuable, une fonctionnalité GitHub qui empêche toute modification ultérieure des actifs de la release. Le contributeur compromis avait fusionné des travaux dans le dépôt de documentation mais n'était pas membre public de l'organisation.

Comment cela fonctionne

L'attaque exploitait la capacité des utilisateurs disposant d'un droit d'écriture à modifier les releases GitHub existantes lorsque l'immutabilité n'est pas activée. Ce paramètre, généralement disponible depuis octobre 2025, verrouille les fichiers et les tags des releases, mais ne protège que celles créées après son activation. OVHcloud n'avait pas activé cette option pour les versions affectées, permettant à l'attaquant de remplacer les binaires sans déclencher de vérifications CI/CD ni d'exécutions de workflows.

Le logiciel malveillant lui-même était un voleur de secrets visant les identifiants stockés sur le disque, tels que ceux dans ~/.ovh.conf ou les variables d'environnement. Des chercheurs d'OpenSourceMalware ont lié le compte compromis à GlassWorm, une campagne connue pour dissimuler du code dans des caractères Unicode invisibles. Bien qu'aucune copie du binaire d'octobre n'ait été analysée publiquement, quatre dépôts personnels associés au compte ont montré des force-pushes en mars contenant des chargeurs cohérents avec les tactiques de GlassWorm.

Détails clés

• Versions compromises : v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 sont considérées comme compromises ; v0.10.0 est propre.
• Plateformes affectées : macOS (x86_64, arm64), Linux (x86_64, arm64) et Windows (x86_64). Les builds Linux i386, Windows i386, Windows arm64 et WebAssembly n'ont pas été touchés.
• Fenêtre d'exposition : De 12h47 à 14h21 UTC le 19 octobre 2026.
• Méthode de détection : Les binaires malveillants affichent une pseudo-version telle que v0.15.1-0.20261013083505-5ead8ef9b43d+dirty et contiennent -ldflags="-s -w", tandis que les releases authentiques affichent des numéros de tag et aucune ligne ldflags.
• Chemins d'installation sûrs : Les utilisateurs de Homebrew étaient protégés car les casks épinglez les hachages SHA-256 originaux, faisant échouer les téléchargements non concordants. Les images Docker et les méthodes go install n'étaient également pas affectées.
• Hachage malveillant : Le SHA-256 de l'archive Linux arm64 substituée pour la v0.15.0 est 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb.

Pourquoi c'est important

Cet incident met en évidence la fragilité de la sécurité de la chaîne d'approvisionnement lorsque l'immutabilité des releases n'est pas appliquée. De nombreux développeurs comptent sur des scripts d'installation ou des téléchargements directs depuis les releases GitHub sans vérifier les signatures cryptographiques ni épingler les hachages. Le script d'installation officiel d'OVHcloud, par exemple, télécharge la dernière archive sans vérifier un hachage, rendant vulnérable tout utilisateur qui l'a exécuté durant la fenêtre de 94 minutes. De même, les jobs CI récupérant des archives sans hachages épinglés auraient silencieusement installé la version malveillante.

Pour les équipes d'ingénierie, cela sert de rappel critique que la confiance accordée aux contributeurs d'un dépôt doit être contrebalancée par des garde-fous techniques. Même si un pipeline de build est sécurisé, la manipulation directe des actifs de release peut le contourner entièrement. Le fait que les utilisateurs de Homebrew aient été protégés démontre la valeur des gestionnaires de paquets qui imposent l'épinglage des hachages, tandis que ceux utilisant des installations manuelles ou des scripts personnalisés ont couru un risque plus élevé. La rotation des secrets est désormais obligatoire pour quiconque a pu exécuter le binaire compromis, car le logiciel malveillant a probablement exfiltré tous les secrets lisibles de la machine hôte.

Ce que vous pouvez faire

• Faites tourner chaque secret stocké sur les machines ayant pu exécuter le CLI compromis, en utilisant une autre machine propre pour effectuer la rotation.
• Supprimez le binaire actuel de l'OVHcloud CLI et installez la version v0.16.0, publiée comme une release immuable avec attestation.
• Vérifiez les archives téléchargées en utilisant la commande GitHub CLI gh release verify-asset v0.16.0 FILE pour garantir leur intégrité.
• Activez l'immutabilité des releases sur vos propres dépôts GitHub pour empêcher la modification non autorisée des actifs de release existants.
• Épinglez les hachages SHA-256 dans les pipelines CI/CD et les scripts d'installation au lieu de compter sur des tags « latest » dynamiques ou des téléchargements non vérifiés.
• Auditez les niveaux d'accès des contributeurs et imposez l'authentification multifacteur pour réduire le risque de compromission de compte.