Le CLI OVHcloud empoisonné 94 minutes par un compte GitHub volé des mois plus tôt via une extension VS Code
Le 19 octobre 2026, un compte GitHub de développeur compromis a remplacé les binaires du CLI OVHcloud (v0.11.0 à v0.15.0) par un voleur de secrets pendant 94 minutes, touchant environ 250 téléchargements. Activez l’immutabilité de vos releases GitHub, signez vos artefacts et retirez les comptes personnels des privilèges de publication.
19 octobre 2026, 14 h 47. Un compte GitHub de développeur OVHcloud, compromis des mois plus tôt, commence à remplacer les binaires des releases du CLI ovhcloud-cli par une version voleuse de secrets. 19 octobre 2026, 16 h 21. Les binaires malveillants sont retirés après 94 minutes de disponibilité, pour environ 250 téléchargements. 20 octobre 2026. L’avis GHSA-862f-55f5-vmvw documente l’incident de bout en bout, avec ses MD5, ses IOC et sa cause racine. La leçon qui dépasse OVHcloud : la chaîne d’approvisionnement a été percée non par une faille du code, mais par un défaut de configuration des releases et un compte personnel compromis via une extension VS Code.
Ce qui s’est passé, heure par heure
L’avis publié sur GitHub par OVHcloud reconstitue la chronologie. À 14 h 47 (UTC+2), le binaire Darwin de la release v0.15.0 est remplacé. À 14 h 57, tous les binaires de v0.15.0 sont empoisonnés. À 15 h 30, l’attaquant redescend la chaîne des releases, de v0.15.0 jusqu’à v0.11.0. À 15 h 50, un client signale une activité suspecte via une issue GitHub. Les investigations commencent à 15 h 57 ; à 16 h 20, OVHcloud scanne l’ensemble de ses dépôts GitHub, et à 16 h 21, tous les binaires malveillants sont supprimés. Le 18 h 52, l’annonce publique est publiée sur X ; à 19 h 16, la version propre v0.16.0, signée, est mise en ligne pour déclencher les notifications de mise à jour.
Deux chiffres cadrent l’incident : 94 minutes de disponibilité du malware, et environ 250 téléchargements. Un périmètre réduit en apparence, mais la nature du payload change tout.
Le payload : un voleur de secrets qui visait tout l’environnement du développeur
Les binaires remplacés étaient le CLI original recompilé avec un module Go nommé envchecker, injecté dans le code et « strippé ». À chaque exécution, le malware crée un dossier temporaire envchecker-[0-9]{9-10}, y copie les fichiers ciblés, prépare une archive, puis l’exfiltre.
La liste des ressources collectées est un inventaire précis de l’environnement d’un développeur en 2026 : les bases SQLite de VS Code, Cursor, Continue et Sourcegraph Cody, la base locale d’OpenCode, les sessions et historiques de l’agent Hermes (~/.hermes/sessions), le répertoire de configuration de Claude, les identifiants AWS, Google Cloud et Azure, la configuration Docker et Kubernetes, la configuration npm, les clés SSH, les identifiants Terraform, .netrc et la configuration globale Git. Autrement dit, de quoi compromettre non seulement la machine, mais aussi tous les services cloud et dépôts auxquels ce développeur avait accès.
L’exfiltration est rudimentaire mais astucieuse : le code s’appuie sur des appels RPC Solana via des endpoints publics (solana.drpc[.]org, api.mainnet-beta.solana[.]com…), en utilisant le portefeuille BHaDaVbdCYFNaKZGn7yLXFneWoJHZgLiBYkHxVrjyALF, puis dépose l’archive sur hxxps://45.32.148[.]174/upload. Une adresse URL que l’attaquant peut changer à tout moment.
La cause racine : une extension VS Code installée en 2025, et des releases non immuables
Le point le plus instructif est la cause racine, documentée sans langue de bois. L’enquête a remonté jusqu’au compte GitHub d’un développeur. Ce compte avait été compromis des mois avant l’incident, le 20 octobre 2025, lorsque le développeur a installé l’extension color-picker-universal 2.8.91 sur son MacBook personnel. Cette extension est liée, par son portefeuille Solana BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC, à l’acteur de la menace Glassworm, déjà documenté pour des vols de comptes GitHub.
Un service Node.js persistant (plist) communiquait avec 162.33.177[.]177. En mars 2026, plusieurs dépôts personnels du compte avaient déjà été compromis, avec le même portefeuille. Le remplacement des releases du CLI OVHcloud n’a pas été opéré depuis le MacBook du développeur, mais en utilisant les clés volées — signe que l’attaquant détenait des identifiants de publication durables.
OVHcloud est limpide sur la faille de configuration qui a rendu l’attaque possible : « le dépôt GitHub n’était pas correctement configuré pour garantir l’immutabilité des releases ». Le code source et la chaîne de build n’ont pas été touchés — seuls les artefacts publiés ont été remplacés. Le correctif a été immédiat : activation de l’immutabilité des releases sur l’ensemble de l’organisation, suspension du compte compromis, revue des comptes en écriture, et publication d’une release v0.16.0 avec tag signé.
Ce que cela change pour la chaîne d’approvisionnement
L’incident illustre trois tendances qui convergent. D’abord, le vol de compte via extension d’éditeur devient un vecteur de supply chain à part entière : un outil installé sur une machine personnelle en 2025 a produit un incident de production en 2026. Ensuite, l’immutabilité des releases est un contrôle bon marché et déterministe — son absence est ce qui a permis de réécrire des binaires déjà publiés. Enfin, le ciblage des bases d’historique des assistants d’IA (Cursor, Continue, Cody, Hermes, Claude) montre que les attaquants considèrent désormais les conversations d’un développeur avec son agent comme un actif à voler au même titre que ses clés.
La réponse de OVHcloud est un modèle de gestion d’incident supply chain : reconnaissance rapide, avis GHSA détaillé avec MD5 et IOC, actions immédiates listées, et plan d’amélioration annoncé (revue des pipelines de build et de publication, signature systématique des commits et des releases, immutabilité systématique, liaison au IAM centralisé). Le signalement du client alink-tothepast et l’analyse de Ivan Kwiatkowski / VirLabs.ai sont crédités.
Verdict
Si vous avez téléchargé le CLI OVHcloud entre 14 h 47 et 16 h 21 (UTC+2) le 19 octobre 2026, considérez les secrets de cette machine comme compromis, faites la rotation de tout ce que l’inventaire du stealer couvre — AWS, GCP, Azure, Docker, Kubernetes, SSH, Terraform, npm — et réinstallez la version v0.16.0. Pour toutes les organisations qui publient sur GitHub, appliquez dès maintenant les deux contrôles qui auraient neutralisé l’attaque : l’immutabilité des releases et la signature des artefacts (ou la provenance), et retirez les comptes personnels des privilèges de publication au profit d’un IAM centralisé. La supply chain se joue désormais moins dans le code que dans la configuration des dépôts et l’hygiène des postes personnels.