Des archives malveillantes de la CLI OVHcloud volent les secrets

En bref

• Le 19 octobre 2026, entre 12:47 et 14:21 UTC, un attaquant utilisant le compte GitHub détourné d’un contributeur a remplacé les archives téléchargeables de cinq versions publiées de la CLI OVHcloud, de v0.11.0 à v0.15.0, par un build voleur de secrets. Les fichiers remplacés ont été disponibles pendant 94 minutes.
• Toute personne ayant installé ou mis à jour la CLI depuis GitHub pendant cette fenêtre, sur macOS x86_64 ou arm64, Linux x86_64 ou arm64, ou Windows x86_64, via le script d’installation officiel, un téléchargement direct de version, une récupération CI sans hachage figé ou la commande de mise à jour de la CLI elle-même, a reçu le build substitué. Homebrew, go install, Docker et les installations antérieures à la fenêtre n’étaient pas affectés.
• Le fondateur d’OVHcloud, Octave Klaba, a indiqué que le binaire recherche les secrets stockés sur le disque de l’utilisateur et que toute personne affectée doit changer tous les secrets qui s’y trouvent. Aucune copie d’une archive substituée n’a été analysée publiquement, et OVHcloud n’a pas précisé combien de copies ont été téléchargées. Le nombre de victimes reste donc inconnu.
• Si vous avez installé ou mis à jour pendant cette fenêtre, considérez tous les secrets lisibles depuis cette machine comme exposés, renouvelez-les depuis une autre machine, supprimez le binaire et installez la version immuable v0.16.0 publiée le soir même, après vérification avec gh release verify-asset.

Suis-je concerné ?

Vous êtes concerné si toutes ces conditions sont réunies :

• Vous avez installé ou mis à jour la CLI OVHcloud entre 12:47 et 14:21 UTC le 19 octobre 2026.
• L’installation provenait de GitHub par l’un des quatre chemins indiqués ci-dessous.
• Votre plateforme correspondait à l’un des cinq binaires remplacés par version : macOS x86_64 ou arm64, Linux x86_64 ou arm64, ou Windows x86_64. Les builds Linux i386, Windows i386, Windows arm64 et WebAssembly sont restés intacts pour toutes les versions.

Les quatre chemins de téléchargement affectés :

• Le script d’installation officiel, install.sh, qui télécharge l’archive de la dernière version sans vérifier son hachage.
• Un téléchargement direct depuis la page GitHub de l’une des cinq versions, sans vérification indépendante.
• Une tâche CI ou une étape de build qui récupère l’archive depuis l’URL de téléchargement de la version sans hachage figé.
• La commande de mise à jour de la CLI elle-même, depuis une installation par script ou manuelle sur macOS ou Linux. Elle télécharge l’archive et remplace le binaire sans vérifier son hachage.

Vous n’êtes pas concerné si l’une de ces conditions s’applique :

• Vous avez installé avec Homebrew. Le cask en vigueur pendant la fenêtre figeait le SHA-256 original de chaque archive, et Homebrew refuse un téléchargement dont le hachage ne correspond pas. Une installation ou une mise à jour brew pendant cette fenêtre aurait donc échoué au lieu d’installer le fichier remplacé. L’historique du cask du tap ne montre aucun changement entre la mise à jour v0.15.0 du 16 septembre et celle de v0.16.0 du 19 octobre. Certains premiers articles présentaient Homebrew comme exposé ; les hachages figés excluent ce chemin d’installation.
• Vous avez utilisé go install ou compilé depuis les sources. Le tag v0.15.0 pointe toujours vers son commit de septembre, 760fd72, et l’arbre source n’a jamais été modifié.
• Vous avez récupéré l’image Docker ovhcom/ovhcloud-cli. Son tag latest avait été poussé pour la dernière fois le 21 septembre, plusieurs semaines avant la substitution, et n’avait pas été reconstruit.
• Vous avez installé avant 12:47 UTC le 19 octobre sans mettre à jour pendant la fenêtre, ou vous n’avez récupéré que les builds Linux ou Windows i386, Windows arm64 ou WebAssembly.

Comment corriger le problème ?

Installez une version propre vérifiée. Pour Linux x86_64, utilisez la CLI GitHub afin de télécharger v0.16.0, de vérifier son attestation avant extraction et d’installer le binaire vérifié :

gh release download v0.16.0 --repo ovh/ovhcloud-cli \
  --pattern 'ovhcloud-cli_Linux_x86_64.tar.gz' &&
gh release verify-asset v0.16.0 ovhcloud-cli_Linux_x86_64.tar.gz \
  --repo ovh/ovhcloud-cli &&
  tar xzf ovhcloud-cli_Linux_x86_64.tar.gz &&
  sudo install -m 0755 ovhcloud /usr/local/bin/ovhcloud

Pour les autres plateformes, sélectionnez l’archive correspondante dans la version v0.16.0 et vérifiez-la avant de l’extraire ou de l’exécuter.

La version v0.16.0 est immuable : GitHub ne permet donc à personne de modifier ses fichiers. Elle porte aussi une attestation de publication, un enregistrement signé de ses fichiers, que la commande de vérification contrôle. À l’avenir, figez le SHA-256 de l’archive dans la CI. Les chemins de téléchargement affectés ne comportaient aucune vérification indépendante de hachage pour rejeter le remplacement. Une tâche CI en aval avec un hachage figé a détecté la substitution.

Que fait le code malveillant ?

Le binaire substitué est un voleur de secrets selon la description d’OVHcloud lui-même, construit depuis une copie locale du dépôt en dehors du pipeline de publication du projet. Aucune copie n’a été conservée ou analysée publiquement.

Klaba a indiqué que le binaire recherche les secrets stockés sur le disque de l’utilisateur et a décrit sa qualité comme médiocre mais fonctionnelle. OVHcloud n’a publié ni les chemins lus, ni la destination des données collectées, ni le nombre de copies téléchargées. Les fichiers substitués ont été supprimés avant que quelqu’un ne les archive : le comportement du payload n’est donc connu que par la description de l’éditeur.

Les métadonnées de build, issues de la sortie go version -m capturée par l’auteur du signalement avant la suppression, établissent comment il a été construit :

• La ligne du module indique v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, une pseudo-version, la valeur générée par Go pour un build depuis un commit sans tag, ici un commit du 13 octobre 2026. Une véritable version utilise son tag plutôt qu’une pseudo-version. Le build propre v0.16.0 d’OVHcloud indique v0.16.0+dirty : le suffixe +dirty apparaît donc aussi dans des builds légitimes. Le marqueur distinctif est ici l’horodatage de pseudo-version 0.20261013083505, associé au commit et aux options de build inattendus.
• Le commit enregistré est 5ead8ef, pas 760fd72, celui vers lequel pointe le tag v0.15.0. C’est un arbre de l’époque v0.16 présenté sous un nom de fichier v0.15.0.
• Une ligne -ldflags="-s -w" est présente. Le pipeline de publication du projet compile avec une option de version que Go omet des options enregistrées, si bien qu’une version légitime ne montre aucune ligne -ldflags.
• vcs.modified=true signifie que l’arbre de travail contenait des changements non commités au moment du build, ce qui est cohérent avec des modifications appliquées à une copie locale. Ce drapeau seul ne montre pas ce qui a changé et ne prouve pas que le build est malveillant.

Comment la substitution s’est-elle produite ?

La substitution nécessitait un seul compte de contributeur détourné avec accès en écriture et l’immuabilité des versions désactivée. Le compte a utilisé l’API GitHub Releases pour remplacer six fichiers sur chacune des cinq versions, en envoyant checksums.txt en dernier afin que les hachages publiés correspondent aux binaires de remplacement.

Étapes reconstituées depuis les enregistrements côté serveur de GitHub par OpenSourceMalware, et corroborées par l’issue #300 de l’auteur du signalement :

1. L’attaquant détenait les identifiants de HassenBF, un contributeur OVH légitime avec accès en écriture à ovhcloud-cli. Ses contributions publiques fusionnées se trouvent dans le dépôt de documentation d’OVHcloud. Le compte était compromis depuis des mois : les 5 et 6 mars 2026, quatre de ses dépôts personnels avaient subi des force-push avec des commits de tête amendés ajoutant un chargeur caché. C’est la plus ancienne utilisation du compte par l’attaquant vérifiée côté serveur.
2. Entre 12:47 et environ 13:12 UTC le 19 octobre, le compte a utilisé l’API GitHub Releases ordinaire pour supprimer puis renvoyer cinq archives de plateformes et checksums.txt sur v0.15.0, puis répéter l’opération sur v0.14.0, v0.13.0, v0.12.0 et v0.11.0. À chaque passage, checksums.txt était envoyé en dernier afin que les hachages publiés correspondent aux nouveaux binaires.
3. Aucun tag n’a été poussé et aucun workflow GitHub Actions ne s’est exécuté. Le workflow de publication ne se déclenche que sur les pushes de tags, et la liste des exécutions ne montre aucun workflow entre le 16 octobre et le push du tag v0.16.0 à 16:00 UTC le 19 octobre. Le pipeline de build du projet n’a donc jamais été touché ; l’attaquant a envoyé directement les fichiers vers les versions existantes.
4. Tous les chemins d’installation affectés récupéraient le nouveau fichier depuis la même URL de version, sans aucune vérification de hachage : le script d’installation n’en a jamais effectué, la commande de mise à jour n’en effectue pas et la CI sans hachage figé récupérait ce qui se trouvait à cette adresse.
5. Une tâche CI en aval dont le propriétaire avait figé le SHA-256 de l’archive Linux arm64 a échoué à 13:50 UTC. Son propriétaire a exécuté go version -m, identifié le build construit hors pipeline et ouvert une issue publique, faute de canal de signalement privé dans le dépôt. OVHcloud a supprimé les fichiers substitués à 14:21 UTC et publié la version immuable v0.16.0 à 17:16 UTC.

La lacune se situe en D : aucun des quatre chemins affectés ne vérifiait indépendamment le fichier téléchargé avant de l’exécuter. La vérification distincte du SHA-256 figé en F a échoué et détecté la substitution avant que cette tâche CI puisse exécuter le remplacement.

Que peut faire un attaquant ?

Un voleur de secrets exécuté sous l’identité de l’utilisateur peut lire et copier les secrets accessibles à ce compte. Considérez les éléments suivants comme exposés, conformément à la consigne d’OVHcloud de changer tous les secrets de la machine affectée :

• Identifiants OVHcloud : identifiants d’API dans ~/.ovh.conf et variables d’environnement.
• Autres secrets lisibles : clés SSH, .npmrc, .netrc, .pypirc, fichiers .env et identifiants cloud ou CI.

Ce sont les identifiants à inventorier et à renouveler ; le payload supprimé n’a pas été analysé publiquement pour établir sa liste exacte de cibles.

Conditions nécessaires à l’attaque :

• Une installation ou une mise à jour pendant la fenêtre de 94 minutes via l’un des quatre chemins affectés, sur l’un des cinq builds de plateformes remplacés.
• Rien de plus. Aucune interaction utilisateur au-delà de la commande normale d’installation, aucune compromission des sources ou du pipeline de build d’OVHcloud, et aucune action de la victime autre que l’exécution de l’outil qu’elle comptait utiliser.

Que faire si je l’ai installé ?

Si vous avez exécuté un build substitué, ou ne pouvez pas prouver le contraire, suivez les recommandations d’OVHcloud, complétées par OpenSourceMalware :

1. Considérez tous les secrets lisibles depuis cette machine comme exposés et renouvelez-les tous depuis une autre machine, car le binaire substitué peut encore être en cours d’exécution sur la machine affectée. Le renouvellement passe en premier : mettre à jour le binaire remplace le programme, mais ne révoque pas une clé déjà copiée.
2. Supprimez le binaire et installez v0.16.0 ou ultérieure, la version immuable publiée le soir même.
3. Vérifiez la nouvelle archive avec gh release verify-asset v0.16.0 FILE --repo ovh/ovhcloud-cli, puis figez le SHA-256 dans toute tâche CI ou tout Dockerfile qui la récupère : c’est l’absence de ce contrôle qui a ouvert le chemin d’attaque.

Comment vérifier si j’ai été compromis ?

Vérifiez le binaire sans l’exécuter. Trois marqueurs distinguent le build substitué. Ces distinctions comptent : affirmer que tout build +dirty ou portant des lignes vcs est malveillant signalerait à tort les versions légitimes d’OVHcloud, qui indiquent v0.16.0+dirty et vcs.modified=true :

go version -m ./ovhcloud

• La ligne du module est une pseudo-version, v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, plutôt qu’un tag de version comme v0.15.0 ou v0.16.0.
• Le commit enregistré est 5ead8ef plutôt que celui du tag, 760fd72 pour v0.15.0.
• Une ligne -ldflags="-s -w" est présente ; les builds de publication légitimes d’OVHcloud ne montrent aucune ligne -ldflags.

Dans une sortie ovhcloud version déjà disponible, une version v0.16.0 légitime indique v0.16.0. La valeur par défaut dans les sources est undefined lorsque l’option de version de publication est omise ; c’est la valeur attendue d’un build autrement inchangé avec les options enregistrées. Ce n’est pas une observation confirmée du payload supprimé. Utilisez les vérifications statiques ci-dessus plutôt que d’exécuter un binaire suspect.

Pour la seule archive disposant d’une paire de hachages publiée, comparez directement :

• v0.15.0 ovhcloud-cli_Linux_arm64.tar.gz, substituée : 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb
• v0.15.0 ovhcloud-cli_Linux_arm64.tar.gz, originale : 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0

Les indicateurs publiés par OpenSourceMalware pour la campagne de compromission de compte sont distincts du binaire CLI, car aucune copie de ce dernier n’a été conservée :

• Compte GitHub détourné : HassenBF (ID 4911006).
• Chargeur : preinstall.js, SHA-256 43df42fd79f6f81e530892b54634598770d6e496796a863c596e616bcb3fec70.
• Script de cycle de vie : entrées "preinstall": "node preinstall.js" dans package.json.
• Portefeuille Solana de dépôt indirect : BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC.
• Fichier de limitation : ~/init.json dans le répertoire personnel sur macOS.

Chronologie

Toutes les heures sont en UTC, d’après les enregistrements côté serveur de GitHub publiés par OpenSourceMalware, l’issue #300 de l’auteur du signalement et les enregistrements de publication.

• 2026-03-05 et 03-06 : quatre dépôts personnels du compte HassenBF subissent des force-push avec des commits de tête amendés et des chargeurs cachés, première utilisation du compte par l’attaquant vérifiée côté serveur.
• 2026-05-25 à 09-07 : le compte continue de faire fusionner des pull requests ordinaires dans le dépôt de documentation d’OVHcloud.
• 2026-10-13 08:35 : le commit 5ead8ef est intégré à main ; le binaire malveillant sera ensuite construit depuis cet arbre avec des modifications supplémentaires non commitées (vcs.modified=true).
• 2026-10-19 12:47 : les premiers fichiers substitués arrivent sur v0.15.0.
• 12:57 : checksums.txt de v0.15.0 est remplacé pour que les hachages publiés correspondent.
• 13:01 à 13:12 : v0.14.0, v0.13.0 et, dans le même passage, v0.12.0 et v0.11.0 sont modifiées ; le remplacement se termine.
• 13:50 : l’issue #300 est ouverte par le propriétaire de la CI dont le SHA-256 figé n’a pas correspondu.
• 14:21 : OVHcloud supprime tous les fichiers remplacés sur les cinq versions.
• 16:00 : le push du tag v0.16.0 lance les workflows de build et de publication.
• 17:16 : v0.16.0 est publiée par le compte de service ovh-cds, immuable et accompagnée d’une attestation ; Klaba publie l’alerte sur X.
• 2026-10-20 : OVHcloud indique que les premières vérifications ne montrent aucun autre dépôt affecté et promet une analyse après incident.
• 2026-10-26 : publication de cet article.

FAQ

Homebrew était-il affecté ?

Non. Le cask en vigueur pendant la fenêtre figeait le SHA-256 original de chaque archive, et Homebrew refuse un téléchargement dont le hachage ne correspond pas. Une installation ou une mise à jour pendant la fenêtre aurait donc échoué explicitement au lieu d’installer le fichier substitué. Les premiers articles citaient Homebrew parmi les chemins exposés, mais l’historique des commits du tap ne montre aucun changement entre le cask v0.15.0 et celui de v0.16.0.

Le code source ou le pipeline de build ont-ils été compromis ?

Non. Le tag v0.15.0 pointe toujours vers son commit de septembre, l’arbre source n’a jamais été modifié et aucun workflow GitHub Actions ne s’est exécuté pendant le remplacement : la liste des exécutions est vide entre le 16 octobre et le push du tag v0.16.0. L’attaquant a envoyé des fichiers vers des versions existantes via l’API Releases avec le jeton d’un compte de contributeur. Le remplacement était possible parce que l’immuabilité des versions était désactivée.

Pourquoi le paramètre d’immuabilité des versions comptait-il ?

Toute personne ayant accès en écriture à un dépôt peut supprimer puis renvoyer les fichiers joints à une version sans que l’URL de téléchargement change, sauf si la fonctionnalité de versions immuables de GitHub est activée. OVHcloud ne l’avait pas activée. Disponible de manière générale depuis octobre 2025, elle verrouille les fichiers et le tag d’une version, mais ne protège que les versions créées après son activation. Elle est désormais activée : v0.16.0 ne peut donc pas être modifiée de la même manière.

Comment savoir que v0.16.0 est propre ?

Elle a été publiée par le compte de service ovh-cds d’OVHcloud plutôt que par un compte personnel, elle est marquée immuable et ses fichiers ne peuvent donc pas être remplacés. Elle porte aussi une attestation de publication que vous pouvez vérifier avec gh release verify-asset v0.16.0 FILE --repo ovh/ovhcloud-cli, en suivant la procédure publiée par GitHub.

Quelqu’un a-t-il réellement été compromis ?

On l’ignore. OVHcloud n’a pas indiqué combien de copies des archives substituées ont été téléchargées pendant les 94 minutes d’exposition, et aucune copie n’a été conservée. Il n’y a donc ni nombre de victimes ni analyse du payload. Pour toute personne ayant utilisé un chemin affecté pendant cette fenêtre, la position prudente consiste à renouveler les secrets indépendamment des preuves disponibles.

S’agit-il de la campagne GlassWorm ?

Le lien avec le compte est réel, mais l’attribution n’est pas prouvée. Les dépôts du compte détourné ont subi en mars des force-push ajoutant des chargeurs reliés, via leur portefeuille Solana de dépôt indirect, à la campagne ForceMemo de GlassWorm. Selon les termes d’OpenSourceMalware, l’hypothèse selon laquelle le même acteur aurait utilisé le compte en octobre est une déduction : aucun élément du binaire d’octobre n’a été relié à GlassWorm, puisqu’aucune copie n’a été conservée.

Repérez les téléchargements sans hachage figé avant la prochaine substitution

Commencez par le guide de scan de code source d’Ostorlab pour examiner les risques des dépôts. Pour OVHcloud en particulier, inspectez les configurations CI et les Dockerfiles à la recherche de téléchargements de versions sans hachage figé. Vérifiez les binaires conservés avec go version -m pour rechercher la pseudo-version v0.15.1-0.20261013083505-5ead8ef9b43d+dirty et la ligne -ldflags="-s -w". Ces vérifications manuelles ne supposent pas qu’un scanner possède une signature dédiée à cet incident.

Références

• The Hacker News, « Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware », 20 octobre 2026, avec les chemins d’exposition, la vérification du tap Homebrew, les marqueurs de détection et la mise en garde contre les conclusions hâtives sur les builds +dirty : https://thehackernews.com/2026/10/hackers-hijack-five-ovhcloud-cli.html (consulté le 26 octobre 2026)
• OpenSourceMalware, « Glassworm Hacks OVH Clouds CLI tool », 19 octobre 2026, chronologie côté serveur, tableau des faiblesses, indicateurs de campagne et limites de l’attribution : https://opensourcemalware.com/blog/glassworm-hacks-ovh-clouds-cli-tool (consulté le 26 octobre 2026)
• Issue #300, capture de la substitution par l’auteur du signalement, sortie go version -m et paire de hachages, ouverte à 13:50 UTC le 19 octobre 2026 : https://github.com/ovh/ovhcloud-cli/issues/300 (consultée le 26 octobre 2026)
• Version v0.16.0 propre et immuable, publiée à 17:16 UTC le 19 octobre 2026, avec sa liste de fichiers et son journal des modifications : https://github.com/ovh/ovhcloud-cli/releases/tag/v0.16.0 (consultée le 26 octobre 2026)
• Script d’installation à v0.15.0, qui télécharge depuis l’URL de version sans vérifier de hachage : https://github.com/ovh/ovhcloud-cli/blob/v0.15.0/install.sh (consulté le 26 octobre 2026)
• Code de mise à jour automatique de la CLI à v0.15.0, qui télécharge le fichier de version et remplace le binaire sans vérifier de hachage : https://github.com/ovh/ovhcloud-cli/blob/v0.15.0/internal/upgrade/install.go (consulté le 26 octobre 2026)
• Documentation des versions immuables de GitHub et annonce de disponibilité générale du 28 octobre 2025 : https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases et https://github.blog/changelog/2025-10-28-immutable-releases-are-now-generally-available/ (consultées le 26 octobre 2026)
• Procédure GitHub de vérification des fichiers de version : https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/verify-release-integrity (consultée le 26 octobre 2026)
• Commit du cask du tap Homebrew en vigueur pendant la fenêtre, figeant le SHA-256 original : https://github.com/ovh/homebrew-tap/commit/b70a654 (référencé via The Hacker News, 26 octobre 2026)
• Dépôt ovh/ovhcloud-cli, CLI officielle pour gérer les services OVHcloud, 218 étoiles au 26 octobre 2026 : https://github.com/ovh/ovhcloud-cli et https://api.github.com/repos/ovh/ovhcloud-cli (consultés le 26 octobre 2026)
• Nombre de téléchargements des fichiers de la version propre v0.16.0, 2 053 pendant la semaine se terminant le 26 octobre 2026 : https://api.github.com/repos/ovh/ovhcloud-cli/releases/tags/v0.16.0 (consulté le 26 octobre 2026)
• Déclarations de Klaba du 19 octobre sur X, citées par OpenSourceMalware et next.ink : https://next.ink/262824/le-client-en-ligne-de-commande-dovhcloud-compromis-par-un-pirate-sur-github/ (référencées via The Hacker News, 26 octobre 2026)