Claude Code a exposé mots de passe et clés dans 1 122 fichiers publics GitHub

Les mots de passe et les clés d'API que des développeurs ont saisis dans des commandes approuvées dans Claude Code se trouvent dans des dépôts publics GitHub, où tout le monde peut les lire. C'est ce que montre une étude de l'entreprise de sécurité Apiiro, publiée le 5 novembre 2026 et relayée par The Hacker News.

Le problème vient du mode « Yes, and don't ask again » (« Oui, et ne plus demander »). En approuvant une commande avec cette option, l'assistant de programmation d'Anthropic enregistre la règle d'autorisation dans le fichier .claude/settings.local.json du projet — et, quand la règle porte sur une commande exacte, la commande entière est enregistrée mot pour mot, y compris tout mot de passe ou jeton saisi, en clair.

Ce qu'Apiiro a trouvé

Les chercheurs ont passé GitHub public au crible et trouvé 104 185 copies du fichier dans 103 617 dépôts. Parmi elles, 1 122 copies (environ 1,1 %) contenaient au moins un secret, soit 1 379 secrets distincts rien que dans les versions actuelles du fichier local. En ajoutant l'historique git, le fichier partagé .claude/settings.json et les journaux de conversation des agents, le total atteint 2 539 secrets dans 1 994 dépôts, impliquant 63 organisations.

  • 379 mots de passe de bases de données — plus d'un tiers des secrets ouvrent un accès direct à une base de données ;
  • 43 identifiants SSH de serveurs publics ;
  • 42 jetons GitHub, GitLab et npm ;
  • 23 clés AWS ;
  • Parmi les cas les plus graves, selon les chercheurs, une clé cloud de niveau administrateur appartenant à un fournisseur de bases de données et le mot de passe propriétaire d'une base de données de dossiers médicaux.

Supprimer le fichier du projet n'annule pas la fuite : les anciennes versions restent dans l'historique git et dans les forks. Les chercheurs ont trouvé 734 autres secrets dans d'anciennes versions du fichier, dans 509 dépôts, et 211 forks de 74 dépôts portant les mêmes secrets. Le lundi de la semaine de publication, tous les fichiers contenant un secret étaient encore sur la branche principale de leur dépôt — et, dans la moitié des cas, depuis au moins 217 jours.

Pourquoi les détecteurs n'ont pas tout vu

Les chercheurs ont testé les détecteurs de secrets gitleaks et TruffleHog sur les 1 122 copies contenant des secrets : gitleaks en a signalé 564 et TruffleHog 643 — et 215 n'ont été signalés par aucun des deux. La plupart des ratés sont des mots de passe saisis dans des commandes, qui ne correspondent à aucun format de clé connu et ressemblent à des mots ordinaires sur une ligne de commande.

Un détail de conception est au cœur du problème : Claude Code ajoute le fichier aux exclusions globales git de l'utilisateur quand il le crée, mais ne l'ajoute jamais au .gitignore du projet lui-même — la protection ne voyage donc pas avec le code. Dans 539 des 1 105 dépôts retracés, un commit signant Claude comme co-auteur a modifié le fichier, ce qui suggère que l'agent lui-même le commite souvent.

Que faire maintenant

La recommandation des chercheurs est de faire tourner les identifiants avant tout nettoyage :

  1. Recherchez .claude/settings.local.json et .claude/settings.json dans votre organisation GitHub et vérifiez l'historique git, même là où les fichiers ont disparu ;
  2. Faites tourner d'abord : changez tous les mots de passe, jetons et clés que ces fichiers ont pu contenir, avant de nettoyer ;
  3. Retirez le fichier local du contrôle de version avec git rm --cached .claude/settings.local.json et ajoutez-le au .gitignore du dépôt ;
  4. Ouvrez le fichier sur votre propre ordinateur et supprimez toute règle contenant un secret, même s'il n'a jamais été envoyé sur GitHub ;
  5. Ne mettez jamais de secrets dans les commandes : référencez-les comme des variables issues d'un gestionnaire de secrets, par exemple $DB_URL, pour que la règle enregistrée conserve le nom de la variable, et non le secret ;
  6. Approuvez des motifs, comme Bash(npm run:*), plutôt que des commandes uniques.

Un vieil avertissement, sans réponse

Des utilisateurs de Claude Code avaient déjà signalé ce comportement : un rapport de bug déposé le 11 août 2025 indiquait que les commandes approuvées contenant des clés d'API et des jetons étaient stockées mot pour mot dans settings.local.json. Un bot automatisé a clos le rapport comme « non prévu » le 3 janvier, après 60 jours sans activité. Selon les chercheurs, les quatre rapports connexes cités dans l'étude ont été clos par le même bot — le plus récent la veille de la publication — et aucun n'a reçu de réponse d'Anthropic.

Il faut préciser la limite de ce qui a été confirmé : Apiiro n'a pas vérifié si les identifiants trouvés fonctionnent encore — un « vrai secret », dans l'étude, désigne une valeur correspondant à un format connu ou à un contexte vérifié, avec l'accord d'un réviseur IA. Une des entreprises averties a confirmé que sa clé était active au moment de la découverte. Sur les 16 agents de programmation dont les chercheurs ont comparé la documentation, Claude Code est le seul dont il est confirmé qu'il enregistre par défaut la commande approuvée complète dans un fichier du projet.

Geekiki a déjà couvert un autre cas de sécurité impliquant Claude Code : Claude a contourné le moniteur de sécurité d'Anthropic avec de la fiction et de l'apiculture.

Sources

Crédit image : The Hacker News.

Note de transparence : cet article a été produit avec l'aide de l'intelligence artificielle, en croisant des informations de sources publiques sur internet, dont l'étude originale d'Apiiro et la couverture de The Hacker News. Les faits ont été vérifiés auprès des sources citées ; consultez les sources originales pour confirmer les détails.

Muse