Des chercheurs de la société de sécurité Apiiro ont passé au crible des dépôts GitHub publics, dont les fichiers de configuration locale de Claude Code, l’historique Git et les journaux de conversation des agents, et y ont trouvé au total 2539 identifiants réels. Ils sont répartis dans 1994 dépôts de code et concernent 63 organisations. Parmi les données exposées figurent des mots de passe de bases de données Azure, des jetons de production Square, des identifiants de connexion SSH root et même le mot de passe propriétaire d’une base de données de dossiers médicaux.
L’origine du problème tient à un bouton sur lequel beaucoup de gens cliquent chaque jour.
Ce qui est enregistré quand on choisit « ne plus demander »
Avant d’exécuter une commande shell, Claude Code demande une autorisation. Lorsque l’utilisateur choisit « Oui, et ne plus demander », cette règle est écrite dans le fichier .claude/settings.local.json du répertoire du projet, et les commandes du même type n’affichent plus de fenêtre de confirmation. Le hic, c’est que ce qui est enregistré est souvent le texte brut de la commande : si celle-ci contient directement une chaîne de connexion à une base de données, un jeton d’API ou une clé, ces éléments sont eux aussi conservés tels quels dans ce fichier.
Selon la documentation d’Anthropic, lors de la création de ce fichier, Claude Code configure Git pour l’ignorer. Les statistiques d’Apiiro montrent que cette protection échoue dans de nombreux cas : le projet est cloné sur un autre ordinateur, un dossier ordinaire n’est initialisé en dépôt Git que plus tard, ou le fichier est ajouté de force au contrôle de version. Dans tous ces cas, settings.local.json peut être poussé avec le reste.
Quelques chiffres fournis par Apiiro :
- Sur GitHub public, il existe 104185 fichiers
settings.local.json, répartis dans 103617 dépôts ; - Parmi eux, 1122 (environ 1,1 %) contiennent de vrais secrets, soit 1379 après déduplication ;
- Sur les 1105 dépôts retracés, 539 comportent des commits cosignés par Claude qui ont modifié ce fichier.
Plus le fichier est volumineux, plus le risque est élevé. Parmi les fichiers de plus de 8 Ko, environ un sur dix cache une vraie clé ; parmi ceux de moins de 500 octets, moins d’un sur cinq cents. Les règles d’autorisation s’accumulent une à une : plus l’utilisateur clique longtemps sur « ne plus demander », plus le fichier se remplit.
Apiiro n’a pas vérifié si ces identifiants sont encore valides. Même si les propriétaires de dépôts suppriment le fichier, les clés peuvent subsister dans l’historique Git et dans les forks existants.
Le problème avait été signalé depuis longtemps
Dès le 11 août 2025, un utilisateur avait signalé dans le suivi de tickets de Claude Code que les commandes approuvées, avec les clés d’API et jetons qu’elles contenaient, étaient enregistrées mot pour mot dans settings.local.json. Ce rapport a ensuite été fermé automatiquement après 60 jours d’inactivité, sans avoir été corrigé.
Plus d’un an plus tard, le même mécanisme a été mis au jour par une analyse systématique. Boris Cherny, responsable de Claude Code, a répondu sur Hacker News que les fichiers de configuration n’ont pas vocation à entrer dans le contrôle de version, que l’équipe étudie des moyens de prévention et envisage d’intégrer directement l’analyse de secrets dans Claude Code ; en attendant, il recommande aux utilisateurs de lancer eux-mêmes un outil de détection de clés pour faire le ménage. Anthropic n’a pas encore indiqué de date de publication pour la version corrigée.
Ce n’est pas non plus la première fois ce mois-ci que Claude Code est pointé du doigt pour le traitement de données en local. Plus tôt dans le mois, on a signalé qu’il joignait l’adresse e-mail de l’utilisateur à certaines requêtes réseau ; la réponse avait alors aussi consisté à publier d’abord une mesure d’atténuation, la version officielle suivant ensuite. Les deux affaires ont en commun que les outils à agents, pour déranger moins l’utilisateur, écrivent des informations sur le disque ou les envoient à l’extérieur, et que les développeurs ont du mal à savoir ce qui est réellement consigné.
Ce que les développeurs peuvent faire dès maintenant
Si vous avez utilisé Claude Code, commencez par chercher dans vos dépôts locaux et distants les fichiers .claude/settings.local.json et .claude/settings.json, pour voir s’ils contiennent des commandes avec des identifiants en clair. Les clés dont la fuite est confirmée doivent être révoquées et réémises ; supprimer le fichier ne suffit pas.
Une habitude plus sûre consiste à ne pas écrire les clés dans les paramètres de ligne de commande, mais à les référencer par des variables d’environnement ou un outil de gestion de secrets ; il faut aussi activer l’analyse de secrets de GitHub ou une vérification équivalente avant commit, afin que ce type de fichier soit bloqué avant le push.
Sources : ITHome, rapport de recherche d’Apiiro, CocoLoop, Ars Technica, The Hacker News ; ont été recoupés le nombre de fichiers de configuration, la proportion de fichiers contenant des clés, le total d’identifiants et le nombre d’organisations touchées.