# OVHcloud CLI compromis - vol de secrets et mise à jour urgente

> CLI OVHcloud compromis : versions v0.11.0 à v0.15.0 signalées, v0.16.0 saine disponible, réponse rapide et secrets à renouveler après exécution.

- URL canonique : [https://forgetaboutit.fr/blog/ovhcloud-cli-compromis-vol-secrets/](https://forgetaboutit.fr/blog/ovhcloud-cli-compromis-vol-secrets/)
- Publication : 2026-10-19T20:06:00.000Z
- Catégorie : Sécurité
- Sujets : OVH, OVHcloud, CLI, Supply chain, Secrets, CI/CD

**Le CLI OVHcloud a été compromis**, alerte Octave Klaba dans un message publié sur LinkedIn. Un attaquant aurait utilisé le compte GitHub d'un développeur pour ajouter un binaire destiné à récupérer les secrets présents sur le disque des machines qui l'exécutent. Les versions **v0.11.0 à v0.15.0** sont signalées dans l'alerte.

**La réaction a été très rapide : 1 h 34 entre la mise à disposition compromise à 14h47 et la détection puis le blocage à 16h21**, selon les horaires communiqués. La **v0.16.0**, présentée comme saine, est désormais disponible sur le dépôt officiel. Mais si vous avez exécuté un binaire concerné, **la mise à jour doit s'accompagner du renouvellement des secrets potentiellement exposés**.

Sources : [alerte d'Octave Klaba](https://www.linkedin.com/feed/update/urn:li:activity:7517991179561660416/) et [publication officielle de la v0.16.0](https://github.com/ovh/ovhcloud-cli/releases/tag/v0.16.0). Point de situation au **19 octobre 2026**, sur la base des premières informations communiquées.

## À quoi sert le CLI OVHcloud ?

Un CLI est une **interface en ligne de commande**. Celui d'OVHcloud permet de piloter des services depuis un terminal plutôt que de passer systématiquement par l'interface web : consulter des ressources, créer des instances, gérer du stockage ou automatiser des opérations d'infrastructure.

Il peut être utilisé sur le poste d'un administrateur, un serveur d'automatisation ou dans une chaîne de déploiement **CI/CD**. C'est un outil légitime, pratique pour rendre les opérations répétables. [La présentation officielle d'OVHcloud](https://www.ovhcloud.com/fr/public-cloud/cli/) décrit son rôle et les services couverts.

Pour agir sur les ressources, le CLI s'authentifie auprès des API. Le [dépôt officiel](https://github.com/ovh/ovhcloud-cli) documente notamment un fichier de configuration `.ovh.conf` et l'utilisation de variables d'environnement. Il évolue donc dans des environnements où se trouvent souvent des accès sensibles.

**C'est précisément ce qui rend la compromission d'un outil d'administration préoccupante : il peut se retrouver au contact des clés qui servent à exploiter la production.**

## Ce qu'Octave Klaba a annoncé

Le scénario décrit est celui d'une **attaque sur la chaîne de distribution logicielle**, aussi appelée attaque *supply chain*. Un outil de confiance sert de point d'entrée pour distribuer un exécutable malveillant.

Selon le message d'Octave Klaba :

- l'attaquant a utilisé le compte GitHub d'un développeur ;
- un binaire destiné à récupérer des secrets sur disque a été ajouté ;
- un client a signalé le problème ;
- OVHcloud a détecté et bloqué l'incident à 16h21, après une mise à disposition compromise signalée à 14h47 ;
- les premières vérifications n'ont pas identifié d'autre dépôt affecté.

L'incident concerne le **CLI distribué depuis le dépôt `ovh/ovhcloud-cli`**. [Source : déclaration d'Octave Klaba](https://www.linkedin.com/feed/update/urn:li:activity:7517991179561660416/).

## Versions compromises et version saine disponible

Voici les repères communiqués dans l'alerte :

| Version | Statut communiqué par Octave Klaba |
| --- | --- |
| v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 | Versions signalées comme compromises |
| v0.10.0 | Version saine |
| v0.16.0 | Version saine, désormais disponible |

**La v0.16.0 est disponible sur le dépôt officiel depuis le 19 octobre.** C'est la version à récupérer pour remplacer un CLI concerné. [Télécharger la release officielle v0.16.0](https://github.com/ovh/ovhcloud-cli/releases/tag/v0.16.0).

Pour vérifier votre exposition, rapprochez **la version, la provenance et la date de téléchargement du fichier**, puis recherchez sur quelles machines il a été exécuté.

## Une détection et une correction particulièrement rapides

Il faut souligner la vitesse de réaction : **94 minutes pour détecter et bloquer la distribution compromise**, d'après les horaires publiés, puis une version saine mise à disposition **le jour même**. Le signalement d'un client, explicitement remercié par Octave Klaba, a participé à cette réponse.

Cette réactivité compte. Elle réduit le temps pendant lequel de nouveaux utilisateurs peuvent récupérer le binaire concerné et permet d'engager rapidement la remédiation. Elle ne permet pas, en revanche, de rappeler des secrets qui auraient déjà été copiés.

**Le risque zéro n'existe pas. La capacité à repérer un incident, couper sa diffusion et fournir rapidement une solution fait une différence majeure.** L'enjeu, pour les équipes qui exploitent une infrastructure, est d'avoir la même capacité de réaction à leur niveau.

## Si vous avez téléchargé ou exécuté un CLI concerné

La première étape consiste à retrouver **où le fichier a été récupéré et où il a été lancé** : postes d'administration, bastions, serveurs de déploiement, images de conteneurs et runners CI/CD.

**Ne relancez pas un binaire suspect, même avec une option destinée à afficher sa version.** Consultez plutôt les journaux d'installation, les historiques de déploiement et les métadonnées disponibles sans l'exécuter. Le téléchargement d'un fichier n'est pas, à lui seul, équivalent à son exécution ; vérifiez aussi si le processus d'installation l'a lancé automatiquement.

Si une exécution est identifiée ou sérieusement suspectée, notre recommandation opérationnelle est de :

1. **Suspendre les usages concernés et isoler les environnements suspects**, en conservant les éléments utiles à l'analyse : fichier, empreinte et journaux, sans réexécuter le programme.
2. **Depuis un environnement sain, révoquer et renouveler les secrets potentiellement accessibles** : accès OVHcloud, clés SSH, jetons Git, identifiants cloud et autres accès présents sur le périmètre concerné.
3. **Rechercher des usages non autorisés de ces accès** dans les journaux des services et plateformes, et invalider les sessions ou autorisations dérivées lorsque c'est nécessaire.
4. **Rétablir un environnement de confiance**, avec la version officielle saine et, selon les constats, une reconstruction du poste ou du runner avant reprise des automatisations.

Octave Klaba demande aux utilisateurs concernés de changer **tous les secrets sur leur disque**. Il ne faut donc pas limiter l'analyse aux seuls identifiants OVHcloud. Créer une nouvelle clé sans désactiver l'ancienne ne ferme pas l'accès d'un attaquant qui l'aurait récupérée.

La rotation des secrets et l'examen des journaux font également partie des recommandations de la [CISA pour d'autres compromissions de la chaîne logicielle](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/419668f).

## De bons outils peuvent limiter les conséquences

On ne peut pas supprimer toute possibilité de compromission. On peut en revanche **réduire ce qu'un outil compromis peut atteindre et accélérer la réponse**.

Quelques mécanismes ont une utilité directe dans ce scénario :

- **Un inventaire des outils et des déploiements** permet de retrouver rapidement les machines qui ont reçu une version donnée.
- **Des identités distinctes et des droits minimaux** évitent qu'un seul poste ou job détienne les accès à toute la production.
- **Des secrets à durée de vie courte, lorsque les services le permettent**, réduisent la durée d'utilisation possible d'un identifiant volé.
- **Des runners isolés et reconstruits régulièrement** limitent les données exposées entre deux exécutions, sans remplacer la révocation des secrets injectés dans un job compromis.
- **Des journaux centralisés et des alertes adaptées** aident à repérer un comportement inhabituel et à suivre les actions réalisées avec les accès concernés.
- **Une procédure de rotation testée** permet de remplacer rapidement les identifiants sans improviser en pleine urgence.

Un scanner de CVE reste utile, mais il ne suffit pas à détecter un binaire malveillant distribué sous le nom d'un logiciel légitime.

Comme pour une [chaîne CI/CD et son infrastructure d'exécution](/blog/cicd-gitlab-cloud-prive-hyperconvergence/), la sécurité ne repose pas uniquement sur le dépôt utilisé : elle dépend aussi des droits, des secrets et des environnements qui exécutent le logiciel.

## Notre lecture opérationnelle

Cet incident rappelle que **la sécurité d'une infrastructure dépend aussi de ses outils d'administration**. La réponse rapide d'OVHcloud est un point positif important. Côté utilisateurs, le travail consiste maintenant à identifier les exécutions éventuelles et à fermer les accès qui auraient pu être exposés.

C'est aussi une bonne raison de traiter l'outillage d'administration comme une partie de l'infrastructure : inventoriée, surveillée et maintenue, avec des responsabilités claires. Dans notre [infogérance des environnements OVHcloud](/infogerance-ovh/), cette maîtrise opérationnelle complète la gestion des serveurs eux-mêmes.

Vous souhaitez revoir vos accès d'administration, vos automatisations ou votre capacité de réaction ? [Échangeons sur votre infrastructure](/contact/).

## Questions fréquentes

### Quelles versions du CLI OVHcloud sont signalées comme compromises ?

Octave Klaba cite v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 dans son alerte. Il présente v0.10.0 et v0.16.0 comme saines. La provenance et la date de téléchargement du binaire doivent aussi être examinées.

### La version v0.16.0 du CLI OVHcloud est-elle disponible ?

Oui. La v0.16.0, annoncée comme saine par Octave Klaba, est disponible sur le dépôt GitHub officiel depuis le 19 octobre 2026.

### Une mise à jour suffit-elle après l'exécution du CLI compromis ?

Non. Remplacer le binaire ne révoque pas des secrets éventuellement dérobés. Il faut aussi renouveler les accès potentiellement exposés depuis un environnement sain et rechercher des utilisations non autorisées.

### En combien de temps OVHcloud a-t-il réagi ?

Selon les horaires communiqués par Octave Klaba, 1 h 34 sépare la mise à disposition compromise à 14h47 de la détection et du blocage à 16h21. La version v0.16.0 a été publiée le même jour.

## Sources

- [Octave Klaba - alerte sur la compromission du CLI OVHcloud](https://www.linkedin.com/feed/update/urn:li:activity:7517991179561660416/).
- [OVHcloud - dépôt officiel ovh/ovhcloud-cli](https://github.com/ovh/ovhcloud-cli).
- [OVHcloud - publication de la version v0.16.0](https://github.com/ovh/ovhcloud-cli/releases/tag/v0.16.0).
- [OVHcloud - rôle et usages du CLI](https://www.ovhcloud.com/fr/public-cloud/cli/).
- [CISA - réponse à d'autres compromissions de la chaîne logicielle, en contexte](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/419668f).