Des mots de passe et des clés API, que des développeurs auraient entrés en validant des commandes dans l’assistant de codage de Claude, se trouvent dans des dépôts GitHub publics. Selon des chercheurs de la société de sécurité Apiiro, 1 122 copies de fichiers spécifiques contiennent au moins un secret. Ce mécanisme repose sur une fonctionnalité de Claude Code : lorsque l’utilisateur sélectionne « Oui, et ne plus demander », l’outil enregistre la commande, mot pour mot, y compris les informations confidentielles, dans un fichier de configuration du projet.

Le fichier incriminé est .claude/settings.local.json. Supprimer ce fichier d’un projet ne suffit pas à effacer la fuite, car les anciennes versions persistent dans l’historique de Git et dans les forks des dépôts. L’avis des chercheurs est donc clair : avant de faire le nettoyage, tous les mots de passe, jetons et clés contenus dans ce fichier doivent être renouvelés.

Ce comportement survient parce que, par défaut, Claude Code demande confirmation avant d’exécuter la plupart des commandes shell. Si l’approbation est donnée, une règle d’autorisation est sauvegardée dans le fichier mentionné. Cette règle peut concerner un motif général, comme « npm test * », ou une commande précise ; si la commande est exacte, tout mot de passe ou jeton tapé dans cette commande est enregistré en clair.

L’omniprésence du secret dans l’historique Git

Malgré les tentatives de Claude Code pour masquer ce fichier, la protection n’est pas universelle. La documentation de l’outil indique qu’il ajoute le fichier aux exclusions globales de Git lors de sa première écriture dans un dépôt, ce qui fait que Git l’ignore sur la machine de l’utilisateur. Mais cette protection ne concerne que cet environnement local ; elle n’a aucun effet sur un fichier qui aurait déjà été commité.

Apiiro a procédé à une recherche massive sur GitHub, identifiant 104 185 copies de ce fichier dans 103 617 dépôts. Parmi elles, 1,1 % des fichiers, soit les 1 122 concernés, contiennent des secrets. Ces fichiers révèlent 1 379 secrets différents. Ces secrets sont variés : plus d’un tiers ouvrent directement des bases de données, incluant 379 mots de passe de bases de données ; on retrouve aussi 43 identifiants SSH pour serveurs publics, 42 jetons pour GitHub, GitLab et npm, ainsi que 23 clés AWS.

Les détenteurs de ces fichiers incluent 63 organisations, majoritairement des sociétés logicielles de toutes tailles. Les cas les plus critiques impliquent une clé cloud de niveau administrateur appartenant à un fournisseur de bases de données, ou le mot de passe de l’administrateur d’une base de données de dossiers médicaux.

Les failles des scanners traditionnels et les mesures à prendre

Les chercheurs ont également souligné une lacune dans les outils de détection de secrets. Bien que des scanners comme gitleaks et TruffleHog aient été utilisés, ils n’ont pas capturé l’intégralité des vulnérabilités. Sur les 1 122 fichiers identifiés, gitleaks a pointé 564 cas, et TruffleHog 643, mais 215 cas sont passés inaperçus par les deux outils. Ces manques sont souvent dus au fait que les scanners recherchent des formats de clés connus, alors qu’un mot de passe tapé dans une commande peut ressembler à un mot ordinaire.

Pour les équipes de sécurité, l’alerte est forte : il faut considérer les dossiers d’agents comme .claude/, .cursor/, ou .gemini/ comme des zones potentiellement porteuses de secrets, assimilables aux fichiers .env, que ce soit sur les ordinateurs portables ou dans les dépôts.

Face à cette situation, les recommandations techniques sont précises. Les développeurs doivent d’abord inspecter l’historique Git de leurs organisations pour trouver les fichiers .claude/settings.local.json et .claude/settings.json, même si le fichier a été supprimé. Ensuite, la rotation des identifiants est primordiale. Enfin, il faut cesser de suivre ce fichier local avec git rm --cached .claude/settings.local.json et l’intégrer dans le fichier .gitignore du projet. Une solution structurelle suggérée est de toujours passer par des variables d’environnement, comme $DB_URL, plutôt que d’intégrer le secret directement dans la commande approuvée.

Sources

• Claude Code’s “Don’t Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub, The Hacker News, 7 novembre 2026
• Claude Code approval files found exposing company secrets on GitHub, says Apirro researchers, iTWire, 7 novembre 2026