Quand le confort devient une fuite d’identifiants
Le plus inquiétant, dans cette affaire, est sa banalité. Un développeur approuve une commande, choisit “Yes, and don’t ask again”, puis Claude Code enregistre la règle pour éviter de redemander l’autorisation. Selon la recherche publiée par Apiiro le 5 novembre, si cette commande contient un mot de passe, un jeton API, une clé cloud ou une chaîne de connexion à une base de données, la commande exacte peut être écrite dans .claude/settings.local.json, dans le dossier du projet . Ce n’est pas une attaque sophistiquée: c’est un artefact de productivité qui se transforme en coffre-fort non protégé.
Apiiro dit avoir trouvé 104 185 copies publiques de .claude/settings.local.json dans 103 617 dépôts GitHub, dont 1 122 fichiers contenant au moins un secret réel . The Hacker News, qui a repris ces résultats le 7 novembre, indique que ces fichiers publics contenaient 1 379 identifiants distincts, dont 379 mots de passe de bases de données, 43 identifiants SSH, 42 jetons GitHub, GitLab et npm, ainsi que 23 clés AWS . En élargissant le périmètre à l’historique git, aux paramètres partagés et aux transcriptions d’agents, Apiiro arrive à 2 539 secrets réels dans 1 994 dépôts publics .
L’échec principal tient à la portabilité de la protection. Claude Code tente d’éviter l’ajout du fichier local à git en l’inscrivant dans la configuration globale d’exclusion de l’utilisateur, mais Apiiro précise que cette protection ne suit pas le dépôt et ne sert à rien si le fichier a déjà été commité . The Hacker News rappelle que les anciennes versions restent dans l’historique git et dans les forks même après suppression du fichier courant . Autrement dit, supprimer le fichier visible ne suffit pas: tout identifiant qui y est apparu doit être considéré comme compromis.
Un risque de chaîne d’approvisionnement, pas seulement de propreté git
Les secrets concernés ne sont pas de simples jetons de test sans valeur. Apiiro cite notamment une clé cloud avec droits d’administration appartenant à un fournisseur de bases de données, un mot de passe Azure Postgres de production, un jeton Square de production, un jeton npm et le mot de passe propriétaire d’une base de données liée à des dossiers médicaux . L’entreprise précise qu’elle n’a pas utilisé ni testé ces identifiants; dans son étude, “secret réel” signifie donc une valeur correspondant à un format connu ou associée à un hôte public, et non la preuve que chaque secret était encore actif . Mais un seul identifiant valide peut suffire à accéder à un compte cloud, cloner du code privé, modifier un paquet ou pivoter vers un système de production.
La limite des scanners aggrave le problème. Apiiro rapporte que gitleaks n’a signalé que 564 des 1 122 fichiers contenant un secret réel, TruffleHog en a signalé 643, et 215 n’ont été détectés par aucun des deux outils . La raison est simple: beaucoup de secrets étaient des mots de passe ordinaires insérés dans des commandes de base de données ou SSH, et non des clés de fournisseurs reconnaissables par préfixe . Les équipes sécurité doivent donc élargir leur définition des fichiers à risque: il ne s’agit plus seulement des .env, mais aussi des fichiers d’approbation, mémoires d’agents, transcriptions, notes de passation et paramètres qui enregistrent “ce qui a fonctionné”.
L’autre fuite: l’e-mail dans le User-Agent
Le deuxième problème est différent, mais il raconte la même histoire: des métadonnées apparemment secondaires peuvent devenir sensibles. Une issue GitHub ouverte le 5 novembre affirme que Claude Code a envoyé l’adresse e-mail de l’utilisateur à des sites tiers arbitraires dans l’en-tête HTTP User-Agent pendant des recherches web . Le rapporteur mentionne Claude Code 2.1.318 sur macOS et affirme que l’exposition a coïncidé avec une hausse d’e-mails frauduleux . Le détail est important: les serveurs web journalisent couramment les User-Agent, ce qui peut propager l’adresse dans des logs d’accès, des outils d’analytics, des CDN, des SIEM et des systèmes de fournisseurs.
VibeIncidents a résumé l’état du dossier le 6 novembre: plusieurs issues GitHub ouvertes rapportaient la présence d’e-mails de compte dans des User-Agent sortants, et un commentaire de contributeur indiquait qu’un mod intégré, cc-plugin-privacy, avait été introduit à partir de la version 2.1.317 pour bloquer ce comportement par défaut . Le même résumé signalait toutefois des rapports de lacunes en 2.1.318 et disait n’avoir trouvé ni CVE ni avis de sécurité GitHub lors de sa vérification . L’analyse publiée par Tin Computer le 6 novembre décrit aussi cette protection comme limitée, en indiquant que la documentation du mod exclut notamment WebFetch, WebSearch, les outils MCP, les scripts contenant l’adresse, les valeurs calculées à l’exécution et les e-mails envoyés sans référence explicite au User-Agent .
Le mécanisme semble relever d’une interaction entre le modèle et son environnement, plutôt que d’une fonctionnalité volontaire de partage d’e-mail. Dans le fil GitHub, une explication citée indique que certains sites, comme Wikipedia, demandent aux clients automatisés de s’identifier avec un contact dans le User-Agent, et que Claude pouvait utiliser l’adresse du compte connecté en construisant une commande curl . Tin Computer décrit le problème de la même manière: l’agent dispose de l’e-mail de connexion et peut le choisir comme contact quand une politique de site en réclame un . La solution robuste n’est donc pas de “mieux demander au modèle”, mais de ne pas fournir de données personnelles inutiles au contexte et d’imposer les règles de sortie hors du modèle.
Claude Dispatch ajoute une surface d’exécution
Le troisième volet déplace le sujet de la fuite de données vers le risque d’exécution de code. The Register a rapporté le 5 novembre que Gal Weizman, chercheur chez Forever Security, avait découvert que l’interface et l’API de Claude Dispatch étaient accessibles depuis une session web ordinaire connectée à claude.ai, ce qui permettrait à une extension de navigateur ayant accès à cette page d’envoyer des commandes à Claude Desktop comme si elles venaient de l’utilisateur légitime . Claude Dispatch sert à envoyer des tâches depuis un téléphone ou un navigateur vers Claude Desktop, lequel peut exécuter des commandes sur l’ordinateur de l’utilisateur .
The Hacker News a précisé le 6 novembre que l’attaque nécessite une extension capable d’exécuter des scripts sur claude.ai, un utilisateur connecté à la fois à claude.ai et à Claude Desktop, ainsi que Dispatch activé . Dans la preuve de concept, un script ouvrait Dispatch, envoyait des invites demandant à Claude d’installer un paquet npm, cliquait automatiquement sur les boutons “Allow”, puis le script d’installation du paquet ouvrait Calculator . La charge utile démontrée était bénigne, mais les deux articles soulignent que la même trajectoire pourrait servir à des actions plus graves si Claude Desktop a accès à des fichiers, identifiants, dépôts ou sessions authentifiées .
L’angle multi-appareils est le plus préoccupant. The Register indique que Dispatch pourrait permettre à une session de navigateur compromise sur une machine de piloter Claude Desktop sur une autre machine connectée au même compte Claude . Un problème d’extension de navigateur devient alors un possible point d’entrée sur un poste de travail, notamment lorsque le même compte personnel relie un ordinateur domestique et un ordinateur professionnel . Les extensions de navigateur étaient déjà sensibles; les agents de bureau les rendent encore plus critiques, car une automatisation au niveau de la page peut se transformer en action au niveau du système d’exploitation.
Les mesures immédiates
La première réponse est l’inventaire. Il faut rechercher .claude/settings.local.json, .claude/settings.json, les transcriptions d’agents, les dossiers .specstory, les fichiers mémoire et les notes de passation dans les dépôts publics et privés, y compris l’historique et les forks . Il faut ensuite faire tourner les secrets avant de nettoyer: si un identifiant apparaît dans un fichier commité ou dans l’historique git, il faut partir du principe qu’il a pu être copié . Les modèles .gitignore au niveau des dépôts doivent inclure .claude/settings.local.json, sans dépendre uniquement d’une exclusion globale locale .
Pour l’usage courant de Claude Code, il faut éviter d’insérer des secrets bruts dans les commandes. Les variables d’environnement, gestionnaires de secrets, identifiants à durée courte et modèles de commandes sans valeurs sérialisées réduisent fortement le risque . Il faut aussi revoir les règles de permission, éviter d’approuver définitivement des commandes exactes contenant des secrets, et considérer “don’t ask again” comme une écriture dans un fichier de politique local, pas comme un simple raccourci d’interface .
Pour la fuite d’e-mail, il faut mettre Claude Code à jour, vérifier que le mod de confidentialité est présent et activé, et ne pas le traiter comme une barrière complète . Les utilisateurs devraient rechercher leur adresse e-mail dans les transcriptions et journaux locaux, définir des contacts publics approuvés pour les projets et éviter que l’adresse de connexion serve de contact automatique . Pour Dispatch, les organisations devraient désactiver les fonctions inter-appareils non nécessaires, restreindre les extensions pouvant agir sur claude.ai et surveiller les installations de paquets ou commandes inattendues lancées par Claude Desktop .
La leçon générale est claire: les agents de code IA font désormais partie de la chaîne d’approvisionnement logicielle. Leurs fichiers de confort, en-têtes HTTP, ponts navigateur-bureau et boîtes de confirmation doivent être modélisés comme des surfaces d’attaque, au même titre que les runners CI, les gestionnaires de paquets et les outils cloud. Les prompts d’autorisation étaient censés être le garde-fou; cette semaine, ils sont devenus une partie de l’incident.
Commentaires
Sois le premier à commenter.