Des mots de passe et des clés d’API de développeurs se sont retrouvés dans des dépôts GitHub publics après que Claude Code a enregistré des commandes approuvées les contenant, selon The Hacker News, qui cite des conclusions révélées par Apiiro. L’entreprise de sécurité a trouvé des secrets dans 1 122 copies publiques de .claude/settings.local.json. Elle recommande de renouveler les identifiants exposés avant de supprimer les fichiers, car des copies peuvent subsister dans l’historique des dépôts et dans les forks.
Les conclusions concernent les développeurs et les organisations qui utilisent l’assistant de programmation d’Anthropic, en particulier ceux qui approuvent des commandes contenant des mots de passe de bases de données, des jetons d’accès ou des clés cloud. Apiiro n’a pas vérifié si les identifiants fonctionnaient encore, bien qu’une entreprise prévenue plus tôt dans la semaine ait confirmé que sa clé était active. On ignore si quelqu’un a déjà utilisé les secrets exposés.
Comment une approbation devient un secret stocké
Claude Code demande normalement l’autorisation avant d’exécuter la plupart des commandes shell. Selon la description que fait The Hacker News de sa documentation sur les autorisations, choisir « Oui, et ne plus demander » enregistre une règle d’autorisation dans le fichier .claude/settings.local.json du projet. Les commandes correspondantes peuvent alors s’exécuter sans nouvelle demande lors des sessions suivantes.
L’autorisation enregistrée peut couvrir un modèle de commande, comme npm test *, ou une seule commande exacte. Lorsqu’elle enregistre la commande exacte, les mots de passe et jetons qui y figurent restent en clair. Apiiro a trouvé de telles règles dans des dépôts publics et a reproduit ce comportement avec les modèles Opus 5.5 et Fable 5.1.
Claude Code dispose d’une protection contre la validation de ce fichier. Sa documentation sur les paramètres indique que, lorsqu’il écrit le fichier pour la première fois dans un dépôt Git, il ajoute le chemin aux exclusions globales Git de l’utilisateur. Git, sur cet ordinateur, ignore alors le fichier dans tous les dépôts.
Mais cette exclusion relève de la configuration d’un seul utilisateur sur un seul ordinateur. Elle ne suit pas le projet, et les chercheurs précisent qu’elle ne protège pas un fichier déjà validé. Claude Code n’ajoute pas non plus le chemin au fichier .gitignore du projet, qui définit les règles partagées d’exclusion des fichiers.
Dans 539 des 1 105 dépôts retracés par Apiiro, un commit désignant Claude comme co-auteur a modifié le fichier de paramètres. Les chercheurs y voient la preuve que Claude valide souvent lui-même ce fichier.
Ce qui a été exposé
Apiiro a analysé 104 185 copies publiques de .claude/settings.local.json réparties dans 103 617 dépôts GitHub. Parmi ces fichiers, 1 122 (environ 1,1 %) contenaient au moins un secret, soit 1 379 secrets différents au total.
Les chercheurs ont compté une valeur lorsqu’elle correspondait à un format de clé connu ou apparaissait comme mot de passe ou jeton à côté d’une adresse de serveur public. Un relecteur fondé sur l’IA devait également approuver la classification.
Plus d’un tiers des secrets donnaient un accès direct à des bases de données, dont 379 mots de passe de bases de données. Parmi les autres découvertes figurent 43 identifiants SSH pour un accès à distance à des serveurs publics, 42 jetons pour GitHub, GitLab et npm, et 23 clés AWS.
Les propriétaires des fichiers comprenaient 63 organisations, surtout des éditeurs de logiciels de tailles variées. Parmi ses découvertes les plus graves, Apiiro met en avant la clé cloud de niveau administrateur d’un éditeur de bases de données et le mot de passe propriétaire d’une base de dossiers médicaux.
Au lundi, tous les fichiers contenant un secret restaient sur la branche par défaut de leur dépôt, c’est-à-dire la branche principale de développement affichée par défaut. Dans la moitié de ces dépôts, le fichier était présent depuis au moins 217 jours.
Supprimer le fichier actuel ne suffit pas à fermer toutes les voies d’exposition. Les versions antérieures contenaient 734 autres secrets répartis dans 509 dépôts, absents de toutes les copies actuelles, généralement parce que le fichier avait été supprimé. Par ailleurs, 211 forks, c’est-à-dire des copies distinctes de dépôts, issus de 74 dépôts, reprenaient les mêmes secrets que leurs originaux.
Apiiro a également trouvé des secrets dans 298 des 76 011 copies de .claude/settings.json, un fichier de paramètres partagé que les équipes valident volontairement, surtout dans des règles d’autorisation. En incluant les paramètres partagés, les versions historiques et les journaux de conversation enregistrés des agents, les chercheurs ont compté 2 539 secrets dans 1 994 dépôts.
Parmi les 16 agents de programmation dont Apiiro a comparé la documentation, Claude Code est le seul dont il a été confirmé qu’il enregistre par défaut la commande approuvée complète dans un fichier de projet.
Les scanners ont manqué les mots de passe en ligne de commande
Apiiro a fait passer les outils de détection de secrets Gitleaks et TruffleHog sur chaque copie, sans l’étape de vérification propre à ces outils. Parmi les 1 122 fichiers de paramètres locaux contenant des secrets, Gitleaks en a signalé 564 et TruffleHog 643. 215 fichiers n’ont été signalés par aucun des deux outils.
La plupart des valeurs manquées étaient des mots de passe intégrés aux commandes. Un outil qui cherche un format de clé reconnaissable peut laisser passer un mot ordinaire placé après PGPASSWORD=, sshpass -p ou mysql -p.
L’exposition peut aussi se produire sans commit GitHub. Le fichier JSON en clair se trouve dans le dossier du projet et peut être inclus dans un paquet npm, une image Docker, une archive ZIP ou un dossier synchronisé. Le rapport cite le ver Shai-Hulud de septembre 2025 comme exemple d’un logiciel malveillant fouillant les postes de développeurs avec TruffleHog, outil qui a signalé plus de la moitié de ces fichiers lors de l’analyse d’Apiiro.
Des utilisateurs avaient déjà signalé ce comportement d’enregistrement. Un rapport de bogue daté du 11 août 2025 décrivait des commandes approuvées contenant des clés d’API et des jetons enregistrés mot pour mot. Un robot automatique l’a fermé avec la mention « non prévu » le 3 janvier, après 60 jours d’inactivité. Apiiro indique que les quatre signalements liés qu’elle cite ont tous été fermés par ce robot sans réponse d’Anthropic ; la dernière fermeture remonte à la veille du rapport.
Renouveler les identifiants avant le nettoyage
Apiiro recommande aux développeurs de chercher dans leurs organisations GitHub les deux noms de fichiers de paramètres et d’examiner l’historique Git, y compris dans les dépôts où les fichiers ont disparu. Tous les mots de passe, jetons et clés que ces fichiers ont contenus devraient être renouvelés avant tout nettoyage.
Les développeurs doivent ensuite cesser de suivre le fichier de paramètres local avec git rm --cached .claude/settings.local.json et ajouter son chemin au fichier .gitignore du dépôt. Ils doivent aussi examiner les copies locales, même celles jamais validées, et supprimer les règles contenant des secrets.
Pour éviter d’enregistrer des identifiants lors des prochaines approbations, Apiiro recommande de faire référence aux secrets par des variables fournies par un gestionnaire de secrets, comme $DB_URL, afin que la règle ne stocke que le nom de la variable. Elle recommande aussi d’approuver des modèles de commandes, comme Bash(npm run:*), plutôt que des commandes individuelles contenant des valeurs sensibles.
Les équipes de sécurité devraient considérer les répertoires des agents, notamment .claude/, .cursor/, .gemini/ et .specstory/, ainsi que les fichiers de mémoire des agents, comme des lieux de stockage potentiel de secrets, à l’image des fichiers de configuration .env, sur les ordinateurs portables comme dans les dépôts. Apiiro recommande d’ajouter ces répertoires et leur historique Git à l’analyse en pre-commit et à l’intégration continue, de s’assurer que les outils détectent les mots de passe présents dans les commandes, et d’inclure .claude/settings.local.json dans les modèles .gitignore de l’organisation. Les chercheurs conseillent de traiter en priorité les identifiants associés à des adresses de serveurs publics, car ils offrent un accès immédiat.
