Une fuite de Claude Code expose des mots de passe dans 1 122 dépôts

Des mots de passe et des clés d’API que des développeurs ont tapés dans des commandes qu’ils ont approuvées dans Claude Code se trouvent dans des dépôts GitHub publics, où n’importe qui peut les lire. L’entreprise de sécurité Apiiro a publié la recherche le 5 novembre 2026. Elle a trouvé 1 122 copies publiques d’un fichier de paramètres de Claude Code contenant au moins un secret.

La cause n’est pas une attaque. C’est un clic d’approbation normal. Quand Claude Code demande d’exécuter une commande d’interpréteur et que l’utilisateur choisit « Oui, et ne plus demander », l’outil peut enregistrer cette commande exacte comme une règle d’autorisation. Si la commande contenait un mot de passe ou un jeton, le secret est enregistré avec elle, en texte clair.

L’annonce

Claude Code est l’agent de codage d’Anthropic qui fonctionne dans le terminal. Par défaut, il demande avant d’exécuter la plupart des commandes d’interpréteur. Sa documentation sur les permissions dit que le choix « ne plus demander » enregistre une règle d’autorisation dans .claude/settings.local.json à l’intérieur du projet, afin que les commandes correspondantes puissent s’exécuter sans demander lors de sessions ultérieures.

Parfois, cette règle est un modèle, comme une commande de test. Parfois, c’est une commande exacte. Apiiro dit que ce deuxième cas est le problème, parce que la règle enregistrée contient la commande mot pour mot. Un mot de passe de base de données tapé après un indicateur, ou un jeton placé dans une ligne de commande, entre dans le fichier sans changement.

L’outil essaie de garder le fichier hors de git. Sa documentation sur les paramètres dit que la première fois qu’il écrit le fichier dans un dépôt git, il ajoute le chemin du fichier au fichier global d’exclusions git pour cet utilisateur. Cette protection vit dans un compte d’utilisateur sur un ordinateur. Elle ne voyage pas avec le projet, et elle ne fait rien pour un fichier qui a déjà été consigné. Apiiro note aussi que Claude Code n’ajoute jamais le fichier au fichier d’ignorance au niveau du projet lui-même.

Dans 539 des 1 105 dépôts avec fuite que les chercheurs ont retracés, une consignation qui listait Claude comme coauteur a changé le fichier. Cela suggère que l’agent a souvent participé à la consignation du fichier même qui contenait le secret. Apiiro dit avoir reproduit le comportement d’enregistrement avec Opus 5.5 et Fable 5.1, et que le comportement appartient à Claude Code lui-même, et non au modèle derrière lui.

Le problème d’échelle en une image : le secret n’est pas dans un fichier, il est dans l’historique, les fourches et les copies. Illustration : Dirty Static

Ce que l’analyse a trouvé

Apiiro a recueilli des données publiques de GitHub du 1er au 3 novembre 2026. Une valeur comptait comme un secret quand elle correspondait à un format de clé connu, ou quand un mot de passe ou un jeton se trouvait à côté de l’adresse d’un serveur public, avec un examinateur d’IA aussi d’accord. Cette méthode compte. Apiiro n’a pas testé les identifiants, donc le compte montre une exposition, et non une mauvaise utilisation prouvée. Les chercheurs ne disent pas si quelqu’un a utilisé ces secrets.

Les cas les plus forts restent saisissants. Ils comprennent une clé infonuagique de niveau administrateur d’un fournisseur de bases de données, un mot de passe Azure Postgres de production, un jeton Square de production, et le mot de passe du propriétaire d’une base de données qui contenait des dossiers médicaux, selon Apiiro. Au total, 63 organisations sont touchées, la plupart étant des entreprises de logiciels.

L’âge rend le résultat pire. Au moment de l’instantané du 2 novembre, chaque fichier contenant un secret était encore sur la branche par défaut de son dépôt. Dans la moitié de ces dépôts, le fichier était là depuis au moins 217 jours. Des versions plus anciennes contenaient 734 secrets de plus dans 509 dépôts, habituellement dans des fichiers qui avaient depuis été supprimés de la copie actuelle.

En comptant ces versions plus anciennes, plus les secrets dans le fichier partagé .claude/settings.json et dans les journaux de clavardage d’agent enregistrés, Apiiro place le total à 2 539 secrets dans 1 994 dépôts. Les fourches ont répandu une partie de cela plus loin, avec 211 fourches de 74 dépôts portant les mêmes secrets que les originaux.

Détails importants

Les analyseurs de secrets normaux en ont manqué une grande part. Apiiro a exécuté gitleaks et TruffleHog sur les copies. Gitleaks a signalé 564 des 1 122 fichiers et TruffleHog en a signalé 643, alors que 215 n’ont été signalés par ni l’un ni l’autre. Les ratés prennent sens une fois que vous voyez la forme. Les analyseurs cherchent des formats de clés connus. Un mot de passe ordinaire à l’intérieur d’une ligne de commande normale peut ressembler à un mot ordinaire.

Nous avons couvert le problème d’hygiène plus large autour des agents de codage auparavant, dans Retirer Postman, les modules d’extension, les crochets dans Codex et Claude Code et dans Exécuter Claude Code, Codex et OpenCode avec Corgi. Ce cas est plus étroit et plus tranchant. Le fichier risqué n’est ni un module d’extension ni un crochet. C’est le registre de permissions que l’outil écrit pour vous.

Ce qu’il faut faire en premier

Apiiro donne un ordre clair, et l’ordre compte. Faites la rotation en premier. Changez chaque mot de passe, jeton et clé que le fichier a jamais contenu, avant de nettoyer le dépôt. Un secret qui s’est trouvé dans un historique public doit être traité comme public, même si le fichier actuel semble propre.

Ensuite, cherchez dans votre organisation GitHub .claude/settings.local.json et .claude/settings.json, et vérifiez l’historique git ainsi que les fichiers actuels. Cessez de suivre le fichier local, ajoutez-le au fichier d’ignorance pour le dépôt lui-même, et ouvrez la copie sur votre propre machine pour supprimer toute règle qui contient un secret.

Puis changez l’habitude qui a alimenté la fuite. Gardez les secrets hors des lignes de commande et référez-vous à eux par des variables provenant d’un gestionnaire de secrets, afin qu’une règle enregistrée contienne un nom de variable et non une valeur. Approuvez des modèles quand vous le pouvez, au lieu d’une commande exacte qui se trouve à porter un identifiant.

Ce qui vient ensuite

Les utilisateurs ont signalé ce comportement longtemps avant l’analyse. Un rapport de bogue déposé le 11 août 2025 disait que des commandes approuvées avec des clés d’API et des jetons étaient stockées mot pour mot dans le même fichier. Apiiro cite quatre reportages liés et dit qu’aucun n’a reçu de réponse d’Anthropic, et que les quatre ont maintenant été fermés par le même robot automatisé, le plus récent cette semaine.

Cette histoire est la partie à laquelle Anthropic doit encore répondre. Faits vérifiés le 8 novembre 2026 : aucune réponse publique d’Anthropic et aucun changement à la documentation sur ce point n’avaient été signalés dans la couverture ci-dessus. Un choix par défaut plus sûr expurgerait les secrets des règles enregistrées, ou refuserait d’enregistrer une commande qui semble en contenir un. Jusqu’à ce que cela arrive, la protection est la vôtre, et elle commence par une recherche dans vos propres dépôts aujourd’hui.

Sources

• Apiiro research, “Coding agents leaking secrets on GitHub,” published November 5, 2026: https://apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again
• The Hacker News, “Claude Code’s ‘Don’t Ask Again’ File Exposes Passwords and Keys in 1,122 Public Copies on GitHub,” November 2026: https://thehackernews.com/2026/11/claude-codes-dont-ask-again-file.html
• Claude Code permissions and settings documentation, linked from the reporting above: https://code.claude.com/docs/en/permissions

Body illustration: Dirty Static. Hero image: Dirty Static.