Claude Code : le fichier des autorisations a exposé plus de 1 300 secrets sur GitHub
Des chercheurs de la société Apiiro ont découvert plus de 1 100 copies publiques sur GitHub d’un fichier de réglages de Claude Code contenant des mots de passe et des clés d’accès. En cause : l’option « ne plus demander », qui enregistre la commande approuvée telle quelle. Ce qui s’est passé et comment s’en protéger.

Une simple option de confort peut-elle exposer les mots de passe d’une entreprise ? C’est ce que montre une étude de la société de sécurité Apiiro, rapportée le 7 novembre 2026 par le site spécialisé The Hacker News. Les chercheurs ont trouvé sur GitHub plus de 1 100 fichiers publics de Claude Code, l’assistant de programmation d’Anthropic, contenant des mots de passe de bases de données, des clés d’accès au cloud ou des identifiants de serveurs. En cause : la manière dont l’outil mémorise les commandes que l’utilisateur a autorisées une fois pour toutes.
D’où vient le problème ?
Claude Code est un agent capable d’exécuter des commandes sur l’ordinateur du développeur. Avant d’en lancer une, il demande l’autorisation. L’utilisateur peut répondre « Oui, et ne plus demander » (« Yes, and don’t ask again »). D’après la documentation officielle d’Anthropic, Claude Code enregistre alors cette approbation sous forme de règle d’autorisation dans un fichier de réglages local, .claude/settings.local.json, placé à la racine du projet.
Une règle peut être un modèle, comme « autoriser toutes les commandes de test », ou une commande exacte. Dans ce second cas, selon les chercheurs, la commande est enregistrée mot pour mot. Si un mot de passe ou une clé y figurait en clair, par exemple pour se connecter à une base de données, il se retrouve copié en texte lisible dans le fichier.
Un fichier exclu de git, mais seulement sur un ordinateur
Anthropic a prévu une protection. Sa documentation indique que la première fois que Claude Code écrit ce fichier dans un dépôt git, il l’ajoute au fichier d’exclusion global de git de l’utilisateur, afin qu’il ne parte pas dans les commits. Mais cette protection ne vaut que pour l’ordinateur concerné. Selon les chercheurs, Claude Code n’ajoute jamais le fichier au .gitignore du projet lui-même, le fichier partagé avec toute l’équipe. Un collègue, un autre poste ou un fichier créé à la main peuvent donc l’envoyer sur GitHub.
Les chercheurs relèvent un autre phénomène : dans 539 des 1 105 dépôts dont ils ont retracé l’historique, un commit signé avec Claude comme coauteur a modifié ce fichier. Ils en déduisent que l’agent lui-même l’a souvent ajouté à un commit.
Ce que les chercheurs ont trouvé
Apiiro a recherché ce fichier dans les dépôts publics de GitHub. Les principaux résultats, tels que rapportés par The Hacker News :
| Indicateur | Résultat |
|---|---|
| Copies publiques du fichier trouvées | 104 185, dans 103 617 dépôts |
| Copies contenant au moins un secret | 1 122, soit environ 1,1 % |
| Secrets différents dans ces copies | 1 379 |
| Mots de passe de bases de données | 379 |
| Total, en incluant l’historique et d’autres fichiers | 2 539 secrets dans 1 994 dépôts |
Parmi les secrets figurent aussi 43 identifiants de connexion à des serveurs, 42 jetons d’accès à GitHub, GitLab ou npm et 23 clés d’Amazon Web Services. Les fichiers appartiennent notamment à 63 organisations, dont, selon les chercheurs, un éditeur de bases de données et le propriétaire d’une base de dossiers médicaux. Dans la moitié des dépôts concernés, le fichier était en ligne depuis au moins 217 jours.
Les chercheurs précisent ne pas avoir testé si ces secrets fonctionnent encore. Une entreprise prévenue a toutefois confirmé que sa clé était active.
Des outils de détection qui passent à côté
L’étude pointe une autre faiblesse : les scanners de secrets courants en ont manqué une partie. Gitleaks a signalé 564 des 1 122 fichiers et TruffleHog 643, et aucun des deux n’a repéré 215 d’entre eux. La plupart des oublis concernent des mots de passe glissés au milieu d’une commande, que ces outils, conçus pour reconnaître des formats de clés, détectent mal.
Un problème propre à Claude Code ?
Sur 16 agents de programmation dont les chercheurs ont comparé la documentation, Claude Code serait le seul confirmé à enregistrer par défaut la commande complète approuvée dans un fichier du projet. Le phénomène n’est pourtant pas nouveau : un signalement déposé sur le dépôt public de Claude Code en août 2025 décrivait déjà ce comportement. Selon The Hacker News, il a été fermé automatiquement par un robot après 60 jours sans activité, comme les quatre signalements liés cités par les chercheurs, sans réponse d’Anthropic. L’article ne fait état d’aucune correction annoncée ni d’aucune déclaration de l’entreprise.
Ce n’est pas la première alerte de sécurité autour des outils de programmation par IA : en octobre 2026, une extension piégée visant les utilisateurs de Claude Code et Cursor avait déjà montré que ces assistants sont devenus une cible.
Que faire si vous utilisez Claude Code ?
Les chercheurs proposent plusieurs mesures, à appliquer dans cet ordre :
- rechercher les fichiers .claude/settings.local.json et .claude/settings.json dans tous les dépôts de l’organisation, historique compris ;
- changer immédiatement tout mot de passe, jeton ou clé qu’ils ont contenu, avant même de nettoyer le dépôt, car un secret publié doit être considéré comme compromis ;
- retirer le fichier du suivi de git et l’ajouter au .gitignore du projet ;
- supprimer les règles locales qui contiennent un secret, même si elles n’ont jamais été publiées ;
- ne jamais taper de secret dans une commande : utiliser des variables d’environnement alimentées par un gestionnaire de secrets ;
- approuver des modèles de commandes, par exemple toutes les commandes d’un script de test, plutôt que des commandes exactes.
Pour les équipes de sécurité, les chercheurs conseillent de traiter les dossiers de configuration des agents (.claude, .cursor, .gemini) comme des fichiers sensibles, de les inclure dans les contrôles automatiques avant chaque publication et d’ajouter le fichier local de Claude Code aux modèles de .gitignore de l’organisation.
Et pour les entreprises en Europe ?
Lorsque des données personnelles sont accessibles par un secret exposé, comme une base de clients ou de patients, l’incident peut constituer une violation de données au sens du RGPD. Le responsable du traitement doit alors la documenter et, si elle présente un risque pour les personnes, la notifier à l’autorité de protection des données, la CNIL en France, dans les 72 heures après en avoir pris connaissance.
Les agents de programmation, nouvelle surface d’attaque
L’affaire illustre un risque plus large : les agents de programmation accumulent dans leurs fichiers de configuration, de mémoire ou d’historique des informations que personne ne relit, et qui finissent par circuler avec le code. À mesure que leur usage se généralise dans les entreprises, la gestion de ces fichiers devient un sujet de cybersécurité à part entière. Les développeurs qui utilisent ces outils au quotidien ont intérêt à vérifier dès maintenant ce que contiennent leurs dossiers de configuration. Une réponse d’Anthropic, qu’il s’agisse de masquer les secrets ou d’ajouter le fichier au .gitignore du projet, réduirait le risque à la source.
Questions fréquentes
Où Claude Code enregistre-t-il les commandes autorisées ?
Lorsque l’utilisateur choisit « Oui, et ne plus demander » pour une commande, Claude Code enregistre une règle d’autorisation dans le fichier .claude/settings.local.json, à la racine du projet, selon la documentation d’Anthropic. Si la règle porte sur une commande exacte contenant un mot de passe, celui-ci y est copié en clair.
Le fichier settings.local.json est-il publié sur GitHub ?
Pas automatiquement. Claude Code l’ajoute au fichier d’exclusion global de git sur l’ordinateur de l’utilisateur. Mais il ne l’ajoute pas au .gitignore du projet : sur un autre poste ou s’il a été créé à la main, il peut être publié. Apiiro en a trouvé 1 122 copies publiques contenant des secrets.
Que faire si un secret a été publié sur GitHub ?
Il faut d’abord changer le mot de passe, la clé ou le jeton concerné, car il doit être considéré comme compromis. Ensuite, retirer le fichier du dépôt et l’ajouter au .gitignore. Supprimer le fichier dans un nouveau commit ne suffit pas, il reste visible dans l’historique.
Comment éviter que Claude Code enregistre des mots de passe ?
La règle la plus sûre est de ne jamais écrire de secret directement dans une commande et d’utiliser des variables d’environnement alimentées par un gestionnaire de secrets. Les chercheurs conseillent aussi d’approuver des modèles de commandes plutôt que des commandes exactes, et de vérifier régulièrement le contenu des fichiers de réglages.
Sources
Références consultées pour la rédaction de cet article. Les adresses sont indiquées à titre informatif et ne sont pas des liens.
- The Hacker News, Claude Code’s Don’t Ask Again file exposes passwords and keys in 1,122 public copies on GitHub, 7 novembre 2026thehackernews.com/2026/11/claude-codes-dont-ask-again-file.html
- Apiiro, Coding agents leaking secrets on GitHubapiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again
- Documentation de Claude Code, Settingscode.claude.com/docs/en/settings



