Une brèche dans OpenCode Console expose les clés API OpenAI, Anthropic et Google de 1,4 % des utilisateurs
Dans la nuit du 16 au 17 octobre 2026, un intrus a accédé à un système legacy d’OpenCode Console en cours de décommissionnement, exposant les clés API OpenAI, Anthropic et Google de 1,4 % des utilisateurs du service. Révoquez et régénérez ces clés chez chaque fournisseur, puis auditez votre facturation depuis le 16 octobre.
16 octobre 2026, dans la nuit. Un intrus atteint un système legacy d’OpenCode Console, en cours de décommissionnement. 17 octobre 2026, au matin. La société Anomaly Innovations notifie par courriel les comptes concernés : 1,4 % des utilisateurs de Console, dont les clés API OpenAI, Anthropic et Google ont pu être exposées. Pourquoi c’est important : l’éditeur relie l’intrusion à une « attaque de distillation à grande échelle » — et une clé de fournisseur volée n’est pas un mot de passe, c’est un compte de facturation ouvert à l’inférence gratuite d’un tiers.
Une brèche dans un système qu’on décommissionnait
OpenCode est un agent de codage open source qui tourne dans le terminal, en application de bureau et dans les IDE. Il est agnostique au modèle : le développeur y branche ses propres clés Anthropic, OpenAI ou Google et bascule de l’une à l’autre. Console, elle, est la couche hébergée et optionnelle du projet : un espace de travail y partage des modèles, fixe des budgets et connecte les fournisseurs des équipes.
C’est précisément cette couche qui a été touchée. Dans son communiqué publié sur X le 17 octobre 2026, l’éditeur explique qu’un tiers a accédé à un système legacy que l’équipe était « en train de mettre hors service ». Les clés de fournisseurs enregistrées dans les espaces de travail concernés — y compris celles d’OpenAI et d’Anthropic — ont pu être exposées. L’éditeur précise que les utilisateurs n’ayant pas reçu de courriel ne sont pas concernés, et que le pourcentage de 1,4 % se rapporte aux utilisateurs de Console, pas à l’ensemble de la base d’OpenCode.
Ce qui manque, et ce qui compte : OpenCode n’a pas expliqué comment l’intrus est entré, combien de temps il est resté, comment les clés étaient stockées, ni si elles ont été effectivement utilisées. Le communiqué établit un lien déclaré avec une opération de distillation, pas un récit technique complet. La prudence impose de traiter toute clé potentiellement exposée comme compromise, pas comme « peut-être compromise ».
Des clés de fournisseurs, pas des mots de passe
L’objet du vol n’est pas une session de connexion : c’est une clé API de fournisseur. La distinction change toute la réponse. Un mot de passe se réinitialise dans l’outil touché ; une clé API se révoque chez le fournisseur — parce que quiconque l’a copiée peut continuer à s’en servir directement, même après sa suppression côté OpenCode.
Les conséquences d’une clé volée sont de trois ordres :
- Facturation : un attaquant peut exécuter des charges de travail sur le compte du propriétaire et faire grimper la note. Plusieurs utilisateurs rapportent des frais qu’ils n’ont pas passés.
- Accès : selon le périmètre de la clé, elle peut aussi atteindre les fichiers téléversés, les prompts stockés et les modèles fine-tunés rattachés au compte.
- Distillation : les sorties de modèles récoltées à grande échelle servent à entraîner un autre modèle, sans autorisation.
Ce troisième point explique le vocabulaire employé par l’éditeur. En septembre 2026, Anthropic avait décrit des campagnes menées par des laboratoires basés en Chine qui avaient extrait environ 190 millions d’échanges de Claude, en partie grâce à des clés API récoltées illégalement. Une clé volée alimente directement ce marché, où elle est consommée vite et à l’échelle. Personne n’a encore attribué publiquement l’attaque d’OpenCode.
Ce qu’il faut faire maintenant
La séquence de remédiation, pour tout utilisateur de Console — qu’il ait reçu le courriel ou non :
- Révoquer chez le fournisseur. Rendez-vous dans le tableau de bord de chaque fournisseur (OpenAI, Anthropic, Google, OpenRouter et les autres) et révoquez-y les clés. N’utilisez pas les liens d’un courriel : les notifications de ce type sont un vecteur de phishing classique.
- Régénérer et redéployer. Créez de nouvelles clés et mettez à jour chaque application, pipeline CI ou agent qui les utilisait. Vérifiez que l’ancienne clé est morte avant de passer à la suite.
- Auditer la facturation. Relisez l’usage et la facturation à partir du 16 octobre : pics de consommation, modèles inconnus, activité à des heures inhabituelles. Posez des plafonds de dépense et des alertes sur chaque compte fournisseur.
- Resserrer le périmètre. Scopez les clés par projet ou par utilisateur pour que la prochaine fuite reste petite. Réinitialisez le mot de passe OpenCode et régénérez les clés Console au passage.
Cyera, qui a publié l’analyse la plus opérationnelle de l’incident, insiste sur un point : supprimer une clé côté OpenCode n’arrête pas quelqu’un qui l’a déjà copiée. Il faut agir à la source, chez le fournisseur. Un plafond de budget Console ne couvre que la dépense qui transite par OpenCode ; il n’empêche pas l’usage direct d’une clé volée contre le fournisseur.
Un problème structurel, pas un incident isolé
La brèche d’OpenCode ne fait que révéler une faille plus large : les agents de codage IA sont devenus, en deux ans, des coffres à clés décentralisés. Cursor, Copilot, Claude Code, Codex et leurs concurrents stockent tous, quelque part, des clés de fournisseurs — dans un fichier local, un gestionnaire de secrets, ou une couche hébergée comme Console. Chaque couche hébergée supplémentaire ajoute une surface d’attaque : un système legacy oublié, un bucket mal configuré, un compte de service mal scopé suffisent.
Le précédent qui inquiète n’est pas théorique. En 2026, une fuite attribuée à l’écosystème DeepSeek avait déjà exposé des clés API et des mots de passe retrouvés dans des données web publiques — la preuve que les secrets mal stockés finissent par circuler. La différence avec une campagne npm classique, comme MALFEX, est instructive : là, l’attaquant publiait des paquets malveillants pour distribuer du code ; ici, il suffit de récolter des identifiants déjà stockés par un tiers. Le rendement est meilleur, et le risque de détection plus faible.
Pour un RSSI, la conséquence est directe : l’inventaire des clés d’inférence doit rejoindre l’inventaire des identifiants de service. On ne peut plus se contenter de surveiller les mots de passe et les jetons cloud ; les clés OpenAI, Anthropic, Google et OpenRouter que vos développeurs distribuent dans leurs outils sont des actifs financiers et d’accès à part entière. Une clé qui dépense 10 000 $ d’inférence en une nuit n’est pas moins grave qu’un accès SSH compromis.
Verdict
Si vos développeurs utilisent OpenCode, demandez-leur s’ils ont reçu un courriel, puis révoquez et régénérez les clés de fournisseurs concernées chez chaque fournisseur — pas seulement dans Console. Si vos équipes utilisent des clés personnelles sans gouvernance, traitez cet incident comme le signal qu’il est : tout outil de codage IA que vos développeurs connectent détient des identifiants et peut atteindre des données. Donnez-lui les mêmes règles de propriété, de rotation et de moindre privilège qu’à un compte de service. La leçon d’OpenCode n’est pas qu’une startup a été compromise ; c’est que la surface d’attaque des clés d’inférence est déjà exploitée à l’échelle industrielle.
Références
- OpenCode — communiqué officiel (X, 17 octobre 2026)
- Cyber Security News — OpenCode Security Breach Exposes Third-Party API Keys (18 octobre 2026)
- Cyera — OpenCode Breach: What Happened and How to Rotate Exposed AI API Keys (17 octobre 2026)
- The Hacker News — OpenCode Console Breach May Have Exposed OpenAI, Anthropic, and Google API Keys (19 octobre 2026)