OVHcloud CLI : cinq releases GitHub piégées

Ce qui se passe

Le lundi 19 octobre 2026, un attaquant s'est servi du compte GitHub détourné d'un contributeur pour remplacer les archives de cinq releases existantes de la ligne de commande d'OVHcloud : v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0, publiées entre le 14 avril et le 16 septembre. Les nouveaux fichiers étaient une compilation conçue pour voler les secrets présents sur le disque de la machine qui l'exécute. Ils sont restés en ligne jusqu'à 94 minutes, de 12:47 à 14:21 UTC. Seuls macOS, Linux (x86_64 et arm64) et Windows x86_64 sont touchés ; les builds Linux i386, Windows i386, Windows arm64 et WebAssembly n'ont pas été modifiés.

OVHcloud a supprimé les archives, puis publié à 17:16 UTC la v0.16.0, une release immuable, c'est-à-dire que GitHub n'en laisse plus modifier les fichiers. Le code source, l'étiquette de version et la chaîne de build n'ont pas été touchés : la mauvaise version est un simple go build d'un commit plus récent, envoyé directement sur les releases, sans passer par le pipeline.

Le mécanisme, et qui est exposé

Tout repose sur un réglage. Sans les releases immuables de GitHub (disponibles depuis octobre 2025, et qui ne protègent que les releases créées après leur activation), quiconque a un accès en écriture au dépôt peut effacer un fichier de release et en envoyer un autre sous le même nom, à la même adresse. L'attaquant a aussi remplacé checksums.txt : les sommes publiées correspondaient donc aux binaires piégés.

Qui reçoit l'archive piégée, et qui la refuse

Exposés si, dans la fenêtre et sur l'une de ces plateformes, vous avez :

lancé le script officiel install.sh, qui ne vérifie aucun hash ;
téléchargé une archive depuis la page de l'une des cinq releases ;
exécuté une CI qui récupère l'archive sans hash épinglé ;
utilisé la commande de mise à jour de la CLI depuis une v0.12.0, v0.13.0 ou v0.14.0, sur macOS ou Linux, pour une installation faite par script ou à la main.

Non exposés : Homebrew, dont la formule épinglait le SHA-256 d'origine et aurait refusé le fichier ; go install et la compilation depuis les sources (la v0.15.0 pointe toujours sur le commit 760fd72) ; l'image Docker, publiée pour la dernière fois le 21 septembre. The Hacker News rectifie les premiers comptes rendus qui rangeaient Homebrew parmi les voies exposées : l'historique du tap ne bouge pas entre le 16 septembre et le soir du 19 octobre.

Comment reconnaître le binaire

Un client dont la CI épinglait le SHA-256 de l'archive Linux arm64 l'a vu échouer, puis a lu les informations de build avec go version -m, qui ne lance pas le programme. Trois indices dans le binaire piégé de la v0.15.0 :

le module vaut v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, une pseudo-version, et non v0.15.0 ;
le commit enregistré est 5ead8ef, pas 760fd72 ;
une ligne -ldflags="-s -w" est présente, alors que le pipeline d'OVHcloud n'en laisse aucune.

Un +dirty ou des lignes vcs ne prouvent rien : la v0.16.0 saine les affiche aussi (v0.16.0+dirty). Le seul hash publié est celui de l'archive Linux arm64 de la v0.15.0 : piégée 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb, d'origine 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0.

Comment s'y prendre

Si vous avez pu exécuter une version piégée, changer tous les secrets lisibles depuis la machine (~/.ovh.conf, variables d'environnement, et tout le reste du disque), de préférence depuis une autre machine.
Supprimer le binaire et installer la v0.16.0. Mettre à jour ne révoque pas une clé déjà copiée, d'où la rotation d'abord.
Vérifier une archive : gh release verify-asset v0.16.0 FICHIER.
Sur vos propres dépôts, activer l'immuabilité des releases, et épingler les hashs en CI.

Ce qu'on ne sait pas

OVHcloud n'a pas dit quels fichiers le binaire lisait, où il envoyait ses données, ni combien d'exemplaires ont été téléchargés ; aucune archive piégée n'a été analysée publiquement. L'entreprise promet un compte rendu détaillé. Les chercheurs d'OpenSourceMalware rattachent le compte à la campagne GlassWorm, mais il s'agit de leur inférence, fondée sur des dépôts personnels modifiés en mars : rien dans le binaire d'octobre n'a pu être relié à cette campagne.

Source : The Hacker News, 20 octobre 2026. Source en anglais.