Les agents de code changent la surface d'attaque des équipes logicielles. Ils lisent des dépôts, lancent des commandes, installent des dépendances, manipulent des tokens et, parfois, s'exécutent dans des environnements proches de la CI ou du poste de développement principal. L'incident codexui-android, documenté fin mai 2026 par la société Aikido Security, est un rappel net : un outil IA apparemment utile peut devenir un vecteur classique d'attaque de la chaîne d'approvisionnement, avec un impact amplifié par les privilèges accordés aux assistants de code.
Faits vérifiés
Le 27 mai 2026, La société Aikido Security a publié une analyse intitulée "Legitimate-Looking Codex Remote UI Secretly Steals Your AI Tokens", mise à jour le 28 mai. Selon Aikido, le paquet publié sur npm et nommé codexui-android se présentait comme une interface web distante pour OpenAI Codex. Le dépôt GitHub associé apparaissait propre, mais le paquet publié sur npm contenait du code malveillant.
Le comportement rapporté est précis : le package cherchait à lire ~/.codex/auth.json ou $CODEX_HOME/auth.json, puis à exfiltrer des données vers sentry.anyclaw.store/startlog. Les champs mentionnés par Aikido incluent notamment access_token, refresh_token, id_token et un identifiant de compte. Aikido indique que l'exfiltration était présente depuis codexui-android@0.1.82.
L'incident a ensuite été recoupé par plusieurs sources. The Hacker News rapporte le 1ᵉʳ juin 2026 que le package était fonctionnel et ne relevait pas d'un simple détournement par nom ressemblant. L'article confirme aussi l'écart important entre un dépôt GitHub propre et un artefact publié sur npm avec du code malveillant. Snyk classe codexui-android comme package malveillant et décrit le vol d'identifiants OAuth Codex depuis ~/.codex/auth.json, avec envoi vers sentry.anyclaw.store.
La société Aikido évoque environ 27 000 téléchargements hebdomadaires au moment de son analyse. The Hacker News et TechRadar mentionnent plus de 29 000 téléchargements hebdomadaires. Ces chiffres donnent un ordre de grandeur de l'exposition potentielle, mais ils ne prouvent pas le nombre de victimes ni le nombre exact d'installations compromises. Un téléchargement depuis npm n'est pas une compromission certaine.
Autre élément important : selon Aikido, une application Android nommée OpenClaw Codex Claude AI Agent tirait codexui-android@latest via pnpm dans un environnement Termux/PRoot. Aikido mentionne aussi une autre application Codex avec plus de 10 000 installations, tout en indiquant que les autres applications examinées ne reposaient pas sur cette infrastructure. Cloud Security Alliance Lab Space ajoute une analyse du risque côté chaîne d'approvisionnement IA, mentionne la variante @friuns/codexui, le compte friuns, hébergé sur le registre npm, et insiste sur la nécessité de considérer auth.json comme un secret.
Analyse
Le point le plus préoccupant n'est pas seulement qu'un paquet npm ait été malveillant. Cela arrive régulièrement dans l'écosystème JavaScript. Le vrai signal, ici, est l'adéquation parfaite entre la cible et les nouveaux usages : un package lié à Codex, installé par des utilisateurs qui manipulent déjà des agents de code, et capable de viser directement le fichier d'authentification local de l'outil.
Les équipes ont souvent une maturité correcte sur les dépendances applicatives de production : fichiers de verrouillage, scans, revues, pipelines, séparation des secrets. En revanche, les outils de productivité développeur échappent encore trop souvent à ce contrôle. Extensions d'éditeur, CLI d'agents, interfaces intermédiaires pour npm, interfaces web locales, intégrations Android, scripts d'installation copiés depuis GitHub : tout cela est parfois traité comme du confort individuel, pas comme une dépendance critique.
C'est une erreur de modèle mental. Un agent de code a souvent plus de capacité opérationnelle qu'une dépendance backend classique. Il peut lire le code source, lancer des builds, inspecter des variables d'environnement, accéder à des fichiers de configuration, modifier des fichiers, déclencher des commandes Git et interagir avec des services distants. Si l'agent ou son interface est compromis, l'attaque ne touche pas seulement une application : elle touche le poste de travail, les secrets, les dépôts et parfois les chaînes CI/CD.
L'autre leçon est la limite du réflexe "j'ai vérifié GitHub". Dans cet incident, les sources rapportent que le dépôt GitHub était propre alors que le paquet npm publié ne l'était pas. Pour un développeur pressé, un dépôt public crédible, une interface fonctionnelle et des téléchargements visibles peuvent suffire à créer la confiance. Or la chaîne d'approvisionnement moderne ne se vérifie pas uniquement au niveau du code source affiché : elle se vérifie au niveau de l'artefact réellement installé.
Le recours à @latest aggrave ce risque. Installer une dépendance mouvante dans un environnement qui contient des tokens revient à laisser l'éditeur du package décider, à chaque installation, du code qui s'exécute localement. Ce n'est pas acceptable pour des outils ayant accès à des secrets. Même pour une petite équipe, l'épinglage des versions n'est pas une sophistication bureaucratique : c'est une barrière simple contre les changements non maîtrisés.
Enfin, cet incident illustre un risque plus large souvent appelé LLMjacking : l'utilisation frauduleuse de comptes, tokens ou quotas liés à des services IA. Si un token Codex ou un jeton assimilé donne accès à des ressources payantes, à des données de compte ou à des capacités d'automatisation, son vol peut produire des coûts, des fuites ou des actions non autorisées. Il faut rester prudent sur les conséquences exactes sans connaître les environnements touchés, mais le principe est clair : un token d'agent IA est un secret de production, même s'il vit sur une machine de développement.
Recommandations
La première mesure est l'inventaire. Listez les outils IA installés sur les postes et environnements de développement : CLI, extensions VS Code ou JetBrains, paquets npm globaux, interfaces intermédiaires locales, applications mobiles liées au développement, scripts définis dans le fichier package.json, conteneurs et images utilisées pour les agents. Pour les freelances, cela peut tenir dans un simple fichier maintenu à jour. Pour une petite équipe, ajoutez un propriétaire, une version approuvée et une date de revue.
Ensuite, auditez les installations existantes. Cherchez explicitement codexui-android et @friuns/codexui dans les fichiers de verrouillage, historiques shell, environnements Termux/PRoot, scripts pnpm, npm ou yarn, et répertoires globaux. Si codexui-android a été installé, notamment dans sa version 0.1.82 ou dans la version désignée par @latest, considérez les tokens Codex présents sur la machine comme exposés. La réponse prudente est la rotation ou révocation immédiate des identifiants concernés, puis la vérification des journaux d'accès disponibles.
Ne vérifiez pas seulement GitHub. Pour les paquets npm sensibles, inspectez l'archive publiée : npm pack, contenu du package, scripts preinstall, postinstall, fichiers générés, différences avec le dépôt source, dépendances transitives. L'objectif n'est pas de transformer chaque développeur en analyste malware, mais d'avoir une procédure renforcée pour les outils qui touchent aux secrets, aux agents ou à la CI.
Évitez @latest pour les outils IA. Épingler les versions, conserver un fichier de verrouillage et mettre à jour volontairement après revue réduit fortement l'exposition aux changements silencieux. Pour les environnements de test ou de démonstration, le confort offert par la version @latest peut sembler acceptable ; pour un agent capable de lire des tokens, il ne l'est pas.
Contrôlez la sortie réseau depuis les machines sensibles et la CI. Une exfiltration vers un domaine déguisé en point de terminaison de monitoring, comme le domaine rapporté dans cet incident, devient plus difficile si les environnements de build et d'agents n'ont pas un accès sortant illimité. En pratique : liste d'autorisation de domaines quand c'est possible, logs DNS/HTTP, alertes sur les nouvelles destinations, et séparation entre poste personnel, environnement agent et CI.
Isolez les agents. Un agent de code devrait idéalement tourner dans une sandbox, un conteneur, une VM ou un environnement à privilèges limités, avec un répertoire de travail borné et des secrets minimaux. Le principe est simple : si l'agent ou un plugin est compromis, il ne doit pas pouvoir lire tout le répertoire personnel, tous les dépôts, tous les tokens et toutes les clés SSH.
Réduisez la durée de vie des secrets. Les tokens de longue durée stockés en clair dans des fichiers locaux sont pratiques, mais ils augmentent l'impact d'un vol. Quand l'écosystème le permet, privilégiez le trousseau du système d’exploitation, des sessions de courte durée, des tokens à portée limitée, et une révocation simple. À défaut, traitez les fichiers comme auth.json avec le même sérieux qu'un .env de production.
Pour les fondateurs et freelances, la politique d'adoption doit être courte, mais explicite. Exemple : aucun nouvel agent ou outil intermédiaire d’IA sans vérification du mainteneur, version épinglée, revue du package publié, exécution dans un environnement isolé, et absence de secrets permanents non nécessaires. Ce n'est pas lourd : c'est le minimum pour ne pas transformer un outil de productivité en accès privilégié incontrôlé.
Ce qu'il ne faut pas conclure trop vite
Il ne faut pas conclure que tous les utilisateurs de Codex sont compromis. Les sources parlent d'un package précis, de versions précises et d'un mode d'installation précis. Il ne faut pas non plus assimiler automatiquement tous les téléchargements depuis npm à des victimes. Les métriques de téléchargement surestiment souvent l'usage réel et ne disent rien, seules, de l'exécution effective du code.
En revanche, il est raisonnable de conclure que les workflows d'agents de code sont devenus une cible rentable. L'incident codexui-android n'est pas seulement une alerte ponctuelle ; c'est un exemple concret de ce qui arrive quand l'outillage IA avance plus vite que les pratiques de sécurité qui devraient l'encadrer.
FAQ
Que dois-je faire si j'ai installé codexui-android ?
Désinstallez le package, identifiez la version installée et considérez les tokens Codex présents sur la machine comme potentiellement exposés. Révoquez ou faites tourner les identifiants concernés, vérifiez les accès récents disponibles, puis inspectez vos scripts, fichiers de verrouillage et installations globales pour éviter une réinstallation.
Est-ce que vérifier le dépôt GitHub suffit ?
Non. Dans cet incident, les sources indiquent que le dépôt GitHub était propre alors que le paquet npm publié contenait le code malveillant. Pour les outils sensibles, il faut vérifier l'artefact réellement installé, pas seulement le dépôt source.
Pourquoi @latest est-il risqué ?
Parce qu'il délègue le choix de la version au moment de l'installation. Si une version malveillante est publiée, un environnement utilisant @latest peut l'installer sans décision explicite de l'équipe. Pour les agents et outils ayant accès à des secrets, les versions doivent être pinées.
Les tokens d'agents IA doivent-ils être traités comme des secrets de production ?
Oui. Même s'ils sont utilisés sur un poste de développement, ils peuvent donner accès à des comptes, quotas, capacités d'automatisation ou données sensibles. Ils doivent être protégés, limités, surveillés et révocables.
Quelle est la mesure la plus importante pour une petite équipe ?
Commencez par un inventaire des outils IA et une règle simple : aucun outil d'agent ne tourne avec des secrets permanents et un accès complet au poste sans revue minimale, version épinglée et isolation. C'est pragmatique, peu coûteux et immédiatement utile.