Si vous avez installé ou mis à jour le CLI d’OVHcloud le lundi 19 octobre 2026 en début d’après-midi, considérez vos secrets comme exposés et changez-les. Pendant 94 minutes, plusieurs versions publiées de l’outil ovhcloud-cli ont été remplacées sur GitHub par un binaire conçu pour récupérer les identifiants stockés sur le disque.
go install ou depuis les sources ne sont pas concernées.Plan de l'article
Que s’est-il passé sur le dépôt ovh/ovhcloud-cli ? #
L’alerte n’est pas venue d’OVHcloud mais d’un utilisateur. Dans un ticket ouvert sur le dépôt GitHub le 19 octobre, il explique que sa chaîne d’intégration continue s’est mise à échouer : elle vérifie l’empreinte SHA-256 de l’archive Linux arm64 du CLI, et cette empreinte venait de changer, des semaines après la publication de la version.
À lire Deno rejoint Cloudflare : ce que l’arrêt du runtime change pour vos projets
Son relevé, tiré de l’API des releases de GitHub, montre que les archives de la v0.15.0 (publiée le 16 septembre) pour Linux, macOS et Windows x86_64 ont été remplacées entre 12 h 47 et 12 h 57 UTC, ainsi que le fichier checksums.txt. Des remplacements similaires touchent la v0.14.0 et la v0.13.0 dans les minutes suivantes.
Octave Klaba, fondateur d’OVHcloud, a confirmé sur X que la publication de 14 h 47 avait été compromise, et que l’entreprise l’avait détectée puis bloquée à 16 h 21. Selon le compte rendu détaillé d’IT-Connect, la liste qu’il a publiée va plus loin que le ticket et inclut aussi les versions v0.11.0 et v0.12.0.
Pourquoi la vérification du checksum n’a servi à rien #
C’est le point qui doit faire réfléchir tous ceux qui distribuent des binaires. L’attaquant n’a pas seulement remplacé les archives : il a aussi réécrit checksums.txt. Un développeur consciencieux qui comparait son téléchargement au fichier d’empreintes de la page de release obtenait donc une correspondance parfaite.
Seule une empreinte enregistrée avant l’attaque, comme celle figée dans la CI de l’utilisateur qui a donné l’alerte, permettait de voir la différence. D’après IT-Connect, le binaire malveillant a été compilé hors de la chaîne de build d’OVHcloud, à partir d’un commit du 13 octobre jamais publié sur le dépôt. Les pipelines CI/CD de l’hébergeur n’ont pas été touchés.
À lire Windows 10 : non, l’ESU ne s’arrête pas ce 13 octobre 2026 — vous êtes couverts jusqu’en 2027
Un compte légitime et une option désactivée
L’attaquant a utilisé le compte GitHub d’un contributeur du projet disposant des droits d’écriture. La cause profonde est plus banale : l’option d’immuabilité des releases n’était pas activée sur le dépôt. Sans elle, un compte suffisamment privilégié peut modifier les fichiers d’une version déjà publiée, sans créer de nouveau tag ni laisser de trace évidente dans l’historique Git.
La correction a été simple. La release v0.16.0, mise en ligne le soir même, est marquée comme immuable par GitHub. « L’option a été activée. Fin de l’incident », a écrit Octave Klaba en présentant ses excuses.
Suis-je concerné ? #
Tout dépend de la manière dont vous installez l’outil. Sont exposés, sur la fenêtre du 19 octobre : le script officiel install.sh, qui ne contrôle pas l’empreinte, les téléchargements manuels depuis la page des releases et, en principe, la commande de mise à jour intégrée au CLI.
Ne sont pas concernés, toujours selon IT-Connect : l’installation par go install ou la compilation depuis les sources, puisque le tag v0.15.0 n’a pas été modifié, et l’image Docker du projet. OVHcloud n’a pas indiqué combien de téléchargements ont eu lieu pendant la fenêtre.
À lire Installer Git : Guide Complet 2026 – Tutoriel
Si vous avez un doute, regardez la date de modification du binaire sur vos postes et vos runners, et l’historique de vos jobs CI qui installent le CLI ce jour-là.
Que faire si vous avez installé une version piégée ? #
Le binaire visait les secrets stockés localement. La rotation doit donc couvrir tout ce qui était lisible par l’utilisateur qui l’a exécuté :
Les identifiants de l’API OVHcloud d’abord, dans le fichier .ovh.conf ou dans les variables d’environnement. Ensuite les clés SSH, les fichiers kubeconfig, les tokens d’autres fournisseurs cloud et de registres de paquets (npm, PyPI, Docker Hub), et les fichiers .env présents dans vos projets.
Passez ensuite à la v0.16.0 ou à une version ultérieure. Les releases immuables sont accompagnées d’une attestation signée que l’on peut vérifier avec la CLI GitHub avant d’exécuter quoi que ce soit.
À lire VCS Version Control : Guide Développeur 2026
Les leçons pour vos propres projets #
Si vous publiez des binaires sur GitHub, activez l’immuabilité des releases. La fonction est disponible pour tous depuis octobre 2025 : une fois publiée, une version ne peut plus voir ses fichiers ni son tag modifiés, et elle reçoit une attestation.
Côté consommateur, l’incident valide une pratique souvent jugée excessive : épingler l’empreinte des artefacts téléchargés dans la CI plutôt que de se fier au fichier de checksums publié à côté. C’est exactement ce qui a permis de repérer l’attaque en moins de deux heures. Pour les outils écrits en Go, installer depuis un tag via go install reste une option plus sûre que le script d’installation.
Enfin, un compte de contributeur reste une cible : authentification forte, tokens à portée limitée et revue régulière des droits d’écriture sur les dépôts qui publient des exécutables.
Questions fréquentes #
La version v0.16.0 est-elle sûre ?
C’est la version publiée par OVHcloud après l’incident, sous forme de release immuable. C’est celle à installer, ou une version plus récente.
À lire Docker prune : Guide nettoyage complet
Mes serveurs OVHcloud ont-ils été piratés ?
Rien ne l’indique. L’incident porte sur l’outil en ligne de commande distribué sur GitHub, pas sur l’infrastructure. Le risque vient des identifiants volés sur les machines qui ont exécuté le binaire.
J’utilise l’image Docker du CLI, dois-je agir ?
D’après l’analyse relayée par IT-Connect, l’image Docker n’a pas été modifiée. Vérifiez tout de même vos autres méthodes d’installation sur la même période.
