Des jetons d’authentification OpenAI Codex volés lors d’une attaque sur la supply chain npm
Le risque lié à la supply chain s’est historiquement concentré sur les dépendances logicielles qui introduisent des vulnérabilités dans les produits compilés — comme l’ont illustré SolarWinds et XZ Utils. Le vol de jetons Codex relève d’un tout autre modèle. Le package compromis n’introduit aucune vulnérabilité dans le code du développeur. Il extrait les identifiants directement de l’environnement du développeur pendant son travail.
Le cycle d’attaque suit un schéma prévisible : un package fonctionnel est publié et téléchargé via les canaux habituels ; il est maintenu et mis à jour, accumulant un historique de commits qui inspire confiance ; du code de collecte d’identifiants est ajouté à un moment donné ; et comme le package fonctionne normalement, les développeurs ne s’en méfient pas. L’exfiltration opère en silence pendant des semaines, voire des mois, avant d’être détectée.
La qualité du camouflage dans le cas Codex est révélatrice. Les identifiants volés étaient envoyés vers un endpoint serveur imitant une intégration Sentry de reporting d’erreurs — un service qui reçoit régulièrement des télémétries d’outils de développement. Une surveillance réseau qui signale les connexions sortantes vers des domaines inconnus ne détecterait pas une connexion vers ce qui ressemble à Sentry. L’attaquant a anticipé et contourné le mécanisme de détection le plus courant pour l’exfiltration de données sortantes.
Les programmes de gestion des risques fournisseurs qui évaluent la posture de sécurité des éditeurs de logiciels doivent élargir leur périmètre pour inclure les écosystèmes de packages dans lesquels ces éditeurs opèrent. Un package npm constitue une relation fournisseur sans aucun processus d’achat associé.
5 points clés à retenir
1. Un package npm fonctionnel a discrètement volé des jetons OAuth Codex pendant un mois.
« codexui-android » — avec environ 29 000 téléchargements hebdomadaires — a collecté les jetons d’authentification OpenAI Codex depuis le stockage local et envoyé l’ensemble des identifiants OAuth à un serveur contrôlé par l’attaquant, déguisé en endpoint Sentry. La même logique d’exfiltration était présente dans deux applications Android totalisant plus de 60 000 téléchargements. Le package remplissait sa fonction annoncée tandis que la collecte d’identifiants s’exécutait en arrière-plan — sans aucun signe apparent pour alerter les développeurs. Les analyses de la supply chain avant publication ne détectent pas ce type de comportement.
2. Les jetons de rafraîchissement n’expirent pas — rendant ce vol particulièrement persistant.
Le fichier ~/.codex/auth.json volé contenait des jetons de rafraîchissement, pas seulement des jetons d’accès. Un attaquant en possession d’un jeton de rafraîchissement peut usurper silencieusement l’identité de la victime indéfiniment, générant de nouveaux jetons d’accès à la demande sans déclencher de nouvelle authentification. La plupart des victimes ne savent pas qu’un vol a eu lieu et ne révoquent donc rien — ce qui fait que la vérification contextuelle continue est plus efficace que l’expiration des jetons comme mesure de contrôle.
3. Le stockage en clair des identifiants est un risque systémique dans les chaînes d’outils des développeurs.
Tout package installé par un développeur peut potentiellement accéder à tous les identifiants stockés dans le répertoire personnel. On retrouve ce schéma dans les CLI des fournisseurs cloud, les systèmes de gestion de versions, les registres de conteneurs et les fournisseurs de services d’IA — tous stockant couramment les identifiants dans des fichiers locaux en clair. Les cadres de gestion des risques fournisseurs conçus pour les éditeurs SaaS doivent être adaptés aux dépendances open source.
4. Les identifiants d’IA volés peuvent ouvrir l’accès aux systèmes de données d’entreprise bien au-delà du poste de travail.
Les jetons Codex donnent accès à tous les systèmes d’entreprise connectés par le développeur — environnements de partage sécurisé de fichiers, pipelines MFT, dépôts de contenus et API internes. Un attaquant muni d’identifiants valides peut interagir avec ces systèmes via des workflows pilotés par l’IA, qui paraissent parfaitement normaux aux systèmes d’audit surveillant les comportements humains inhabituels.
5. L’application du Zéro trust limite les conséquences même en cas de vol d’identifiants.
Les conditions de politique appliquées aux données sensibles — et non seulement l’identité liée à l’identifiant — déterminent si l’accès est accordé. La protection des données selon le principe du Zéro trust implique qu’un jeton volé, utilisé depuis un lieu inattendu, à une heure inhabituelle, ou pour des données hors du périmètre habituel, peut échouer à l’évaluation de la politique, même si le jeton est techniquement valide. Le serveur Secure MCP de Kiteworks constitue le point de contrôle que les jetons contrôlés par l’attaquant ne peuvent pas contourner.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Pourquoi le stockage en clair des identifiants est un risque systémique
Le fichier ~/.codex/auth.json stocke les identifiants OAuth en clair parce que c’est la solution la plus simple pour les outils de développement. Les développeurs veulent que leurs outils s’authentifient sans friction. Les fichiers d’identifiants sur le système local, lisibles par tout processus lancé par le développeur, répondent à ce besoin efficacement — tout en créant un point de défaillance unique : tout processus ayant accès en lecture au système de fichiers peut récupérer tout ce qu’il faut pour usurper le compte.
Ce problème ne se limite pas à Codex. On retrouve le même schéma dans les chaînes d’outils des développeurs — CLI cloud, systèmes de gestion de versions, registres de conteneurs, fournisseurs de services d’IA, tous stockant couramment les identifiants dans des fichiers locaux en clair. Les équipes de sécurité focalisées sur les contrôles d’accès réseau et la défense périmétrique négligent souvent totalement cette surface locale d’identifiants.
Tout package installé par un développeur peut accéder à tous les identifiants stockés dans le répertoire personnel. Les cadres de gestion des risques tiers conçus pour les éditeurs SaaS et les fournisseurs cloud doivent être adaptés aux dépendances open source. Les identifiants au repos doivent bénéficier du même traitement que les données sensibles au repos : chiffrement avec des clés stockées séparément du contenu chiffré.
Comment des identifiants IA volés deviennent des violations de données d’entreprise
Le vol de jetons Codex n’est pas qu’un simple compromis de compte — c’est la première étape d’une chaîne pouvant aboutir à l’exfiltration de données d’entreprise. Un développeur installe un package malveillant ; le package collecte les identifiants Codex ; l’attaquant utilise ces identifiants pour accéder à tous les systèmes d’entreprise accessibles au compte du développeur ; il extrait ensuite du contenu sensible via des canaux qui ressemblent en tout point à l’activité légitime du développeur.
Les systèmes de données d’entreprise les plus exposés sont ceux auxquels les outils d’IA se connectent de plus en plus : dépôts de documents, plateformes de partage sécurisé de fichiers, salles de données virtuelles et pipelines de transfert sécurisé de fichiers. Ces systèmes hébergent des contrats, des données financières, de la propriété intellectuelle et des informations personnelles réglementées. Un attaquant muni d’identifiants Codex d’un développeur peut interagir avec ces systèmes via des workflows pilotés par l’IA, qui paraissent parfaitement normaux aux systèmes d’audit surveillant les comportements humains inhabituels.
Kiteworks interrompt cette chaîne au niveau de l’accès aux données. Le serveur Secure MCP contrôle quels outils d’IA peuvent interagir avec les données d’entreprise — si l’identité de l’outil ou le contexte de la politique ne correspond pas à l’ensemble autorisé, il ne peut pas accéder aux données, quels que soient les identifiants présentés. L’application de l’ABAC va plus loin : elle évalue non seulement qui fait la demande, mais aussi les attributs qui décrivent la requête, les données et le contexte opérationnel. Un jeton volé utilisé depuis une zone géographique inhabituelle, à une heure inhabituelle, ou pour des données hors du périmètre habituel du développeur, peut échouer à l’évaluation de la politique même si le jeton est valide.
Comment réagir aux compromissions de la supply chain des outils IA
Lorsqu’un vol d’identifiants de ce type survient, la réponse s’articule autour de deux axes : contenir l’exposition immédiate et mettre en place des contrôles pour éviter la récidive. La première étape consiste à révoquer tous les jetons potentiellement compromis — tout développeur ayant installé le package concerné pendant la période d’exposition doit considérer ses identifiants auth.json comme compromis. La révocation des jetons est une opération manuelle dans la plupart des implémentations OAuth, et les organisations qui ne disposent pas d’un inventaire des développeurs et de leurs identifiants de service auront du mal à la mener à bien.
Un plan de réponse aux incidents couvrant la compromission de la chaîne d’outils IA doit inclure la détection automatisée des accès aux fichiers d’identifiants par des processus non autorisés, des procédures de révocation des jetons à l’échelle de l’entreprise, et une revue des systèmes d’entreprise accessibles via les identifiants IA des développeurs. Les journaux d’audit retraçant les accès aux données via l’IA sont essentiels pour déterminer ce qu’un attaquant a réellement consulté pendant la période d’exposition — c’est la base de preuve pour savoir si des données réglementées ont été impliquées.
Pour en savoir plus sur la protection de vos données sensibles contre les attaques sur la supply chain IA, réservez votre démo sur mesure dès aujourd’hui.
Foire aux questions
L’attaquant a acheminé les identifiants volés via un endpoint imitant une intégration Sentry de reporting d’erreurs — un trafic que la plupart des surveillances réseau ne signaleraient pas. Le package fonctionnait également correctement, sans aucun signe apparent pour les développeurs. Les scans de registre avant publication recherchent des signatures malveillantes connues, mais ne simulent pas le comportement à l’exécution qui révélerait un accès aux identifiants. La gestion des risques supply chain doit inclure une analyse comportementale à l’exécution des packages installés, et non se limiter à la vérification des signatures à l’installation.
Les jetons d’accès expirent après quelques minutes ou heures. Les jetons de rafraîchissement permettent de générer de nouveaux jetons d’accès indéfiniment, tant qu’ils ne sont pas explicitement révoqués — et la plupart des victimes ignorent qu’un vol a eu lieu, donc ne les révoquent jamais. Les principes du Zéro trust répondent à cela via une vérification contextuelle continue : les jetons utilisés dans des contextes inhabituels sont signalés même s’ils sont techniquement valides. L’application ABAC de Kiteworks applique cette évaluation contextuelle à chaque demande d’accès aux données, indépendamment de la validité du jeton.
Oui. Les identifiants OAuth devraient être stockés dans des coffres-forts gérés par la plateforme — trousseau système macOS, gestionnaire d’identifiants Windows ou module de sécurité matériel pour les déploiements en entreprise — et non dans des fichiers JSON en clair dans le répertoire personnel. Les coffres-forts de la plateforme exigent une authentification explicite de l’utilisateur avant de libérer les identifiants, rendant l’accès silencieux en arrière-plan par un package malveillant bien plus difficile. Les organisations doivent également auditer régulièrement quels outils de développement peuvent accéder aux identifiants des systèmes d’entreprise dans le cadre de leur programme de gestion des risques fournisseurs.
Tout dépend des systèmes d’entreprise accessibles avec ces identifiants. S’ils permettent d’accéder à des dépôts de documents, des plateformes de partage sécurisé de fichiers ou des pipelines MFT, un attaquant peut interagir avec ces systèmes via des workflows pilotés par l’IA. Les données réglementées — informations médicales protégées (PHI) couvertes par la HIPAA, données personnelles couvertes par le RGPD, CUI relevant du CMMC — se retrouvent directement exposées. Traitez les identifiants IA compromis avec la même urgence que des identifiants utilisateurs privilégiés compromis.
Kiteworks applique les politiques d’accès au niveau des données, et pas seulement à l’authentification. Le serveur Secure MCP contrôle quels outils d’IA sont autorisés à interagir avec les données d’entreprise — une identité d’outil non reconnue ne peut pas accéder au contenu protégé, quels que soient les identifiants présentés. La passerelle de données IA et l’application ABAC évaluent l’ensemble du contexte de la requête — identité, outil, classification des données, environnement et comportements — de sorte qu’un jeton volé utilisé dans un contexte inhabituel échoue à l’évaluation de la politique, même s’il n’a pas encore été révoqué. Chaque interaction génère une piste d’audit infalsifiable.
Ressources complémentaires
- Article de blog
Stratégies Zéro trust pour protéger la confidentialité de l’IA à moindre coût - Article de blog
Pourquoi 77 % des organisations échouent à sécuriser les données IA - eBook
AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.