Le 17 octobre 2026, OpenCode a confirmé qu’un accès non autorisé à un ancien système en cours de retrait avait pu exposer les clés d’API de fournisseurs externes (OpenAI, Anthropic, Google) enregistrées par une partie des utilisateurs de son service OpenCode Console. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : mode opératoire, correspondance avec MITRE ATT&CK, détection, questions d’audit ISO 27001 et pistes de sensibilisation. Elle repose sur la communication de l’éditeur et sur des témoignages d’utilisateurs relayés par Notebookcheck et Cyberattaque.org : le vecteur d’entrée, le mode de stockage des clés et l’ampleur réelle ne sont pas publiés.
Pour une lecture orientée dirigeant, voir notre décryptage « Clés d’IA volées : quand un outil en ligne fait payer ses clients ».
Contexte
- Service : OpenCode est un agent de développement open source compatible avec de nombreux modèles. Le service hébergé OpenCode Console permet d’enregistrer dans un espace de travail les identifiants de fournisseurs externes ; la console les injecte dans les requêtes transmises à son API, et les fournisseurs facturent directement la consommation (Cyberattaque.org, 17 octobre 2026, d’après la documentation de l’éditeur). Les clés conservées uniquement en local dans le client ne sont pas mentionnées dans l’alerte.
- Ampleur : 1,4 % des utilisateurs de la console, sous-ensemble de ceux ayant relié des fournisseurs externes ; nombre absolu non communiqué. Notification par e-mail le 17 octobre ; selon l’éditeur, l’absence de courriel signifie l’absence d’impact identifié (Notebookcheck, 17 octobre 2026).
- Chronologie : incident situé dans la nuit du 16 au 17 octobre 2026 ; toujours en cours selon l’éditeur, qui travaille avec Anthropic, OpenAI et Google.
- Attaquant : non identifié, aucune revendication. L’éditeur rattache l’usage des clés à une « attaque de distillation à grande échelle ».
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| Accès initial | Accès non autorisé à un « système legacy » en cours de démantèlement ; méthode non publiée | Non déterminable à ce stade |
| Accès aux secrets | Clés de fournisseurs enregistrées dans certains espaces de travail potentiellement exposées ; protection au repos non documentée | Hypothèse : T1552 Unsecured Credentials ou T1555 Credentials from Password Stores |
| Usage des clés | Requêtes envoyées aux API des fournisseurs avec les clés des victimes | T1078.004 Valid Accounts: Cloud Accounts |
| Impact | Consommation facturée aux victimes (signalements individuels de l’ordre de 200 à 400 dollars ou euros, un projet Google suspendu pour abus) ; collecte de réponses de modèles selon l’éditeur | T1496.004 Resource Hijacking: Cloud Service Hijacking ; la distillation elle-même n’a pas d’équivalent direct |
| Autres données | Aucune indication de vol de mots de passe, de conversations, de code ou de données bancaires | Non applicable |
Faits techniques connus
- Les secrets concernés sont des identifiants de fournisseurs tiers stockés côté serveur par un intermédiaire, pour être réutilisés au nom de l’utilisateur : un modèle de « coffre délégué » courant dans les outils d’IA et d’automatisation.
- Le système compromis était en cours de retrait mais contenait encore des secrets actifs.
- L’usage frauduleux se fait depuis l’infrastructure de l’attaquant, directement contre les API des fournisseurs : l’intermédiaire ne voit pas forcément ces requêtes.
- Mesures demandées : révocation et remplacement des clés chez chaque fournisseur, mise à jour des applications qui les utilisent, revue de l’historique de consommation.
Ce qu’on ne sait pas
- Le vecteur d’entrée sur l’ancien système, et la raison pour laquelle il donnait encore accès aux clés.
- Le mode de stockage des clés (chiffrement, gestion des clés de chiffrement, cloisonnement entre espaces de travail).
- Le nombre de comptes touchés, le volume de requêtes frauduleuses et l’existence éventuelle d’autres victimes chez d’autres intermédiaires.
Détection : la facture comme premier capteur
- Côté utilisateurs : selon les témoignages relayés par Notebookcheck, des alertes de consommation d’OpenAI et d’Anthropic sont arrivées avant la notification de l’éditeur, et Google a suspendu au moins un projet pour usage excessif. Les mécanismes de facturation des fournisseurs ont joué le rôle de détecteur.
- Côté éditeur : le mode de détection n’est pas publié.
- Pourquoi l’abus passe inaperçu : clés valides, requêtes conformes à un usage normal de l’API, absence de lien avec une session d’utilisateur ; sans plafond ni alerte, la seule trace est la facture. Les systèmes en fin de vie sortent souvent du périmètre de surveillance et de mise à jour avant d’être réellement éteints.
- Signaux à surveiller : pics de consommation hors des horaires habituels, modèles appelés que l’équipe n’utilise pas, volume de requêtes sans rapport avec l’activité, suspension ou avertissement d’abus émis par un fournisseur.
Questions d’audit ISO 27001:2022
- A.5.17 (informations d’authentification) : « Tenez-vous un inventaire des clés d’API et secrets techniques donnant accès à des services payants (IA, cloud, messagerie, SMS), avec leur propriétaire, leur lieu de stockage, leur date de création et leur règle de renouvellement ? Comment une clé est-elle révoquée en urgence ? »
- A.5.19, A.5.22 et A.5.23 (relations fournisseurs, surveillance des services fournisseurs, services en nuage) : « Lorsque vous confiez des secrets à un service en ligne, avez-vous évalué comment il les protège (chiffrement, cloisonnement, gestion de ses systèmes anciens) ? Êtes-vous informés de ses incidents et de ses changements d’architecture ? »
- A.8.16 (activités de surveillance) : « Des plafonds de dépense et des alertes de consommation sont-ils configurés chez chaque fournisseur d’IA ou de cloud ? Qui reçoit ces alertes et quelle est la conduite à tenir ? »
- A.8.10 (suppression des informations) et A.5.9 (inventaire des informations et autres actifs associés) : « Lors de l’arrêt d’un système ou de la fin d’un contrat, la procédure prévoit-elle de révoquer les secrets qu’il contenait ou utilisait ? Les systèmes en cours de démantèlement restent-ils dans le périmètre de surveillance jusqu’à leur arrêt complet ? »
Pistes de sensibilisation
- Pour les développeurs et les équipes data : atelier « Une clé d’API est une carte bancaire sans plafond ». Recenser les clés utilisées par l’équipe et leur lieu de stockage (code, fichiers de configuration, outils en ligne), régler un plafond et une alerte chez chaque fournisseur, puis rejouer une révocation complète. Pour la partie réaction, s’appuyer sur la fiche réflexe « Piratage de compte » de Cybermalveillance.gouv.fr.
- Pour les dirigeants et les utilisateurs d’outils d’IA : « Qui paie quand l’IA travaille ? ». Dix minutes pour faire le point sur les abonnements et clés d’IA de l’entreprise, avec les conseils pour utiliser l’IA de Cybermalveillance.gouv.fr comme support.
À lire aussi : notre décryptage pour les dirigeants, « Clés d’IA volées : quand un outil en ligne fait payer ses clients », et le bulletin de veille du 19 octobre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.