La fonctionnalité « Ne plus demander » de Claude Code expose des secrets dans des dépôts publics

Les mots de passe et les clés API saisis dans des commandes shell approuvées via Claude Code d’Anthropic sont exposés dans des dépôts GitHub publics. La société de sécurité Apiiro a rapporté le 6 novembre 2026 que l'assistant IA sauvegarde ces identifiants en texte brut lorsque les utilisateurs sélectionnent l'option « Oui, et ne plus demander ».

Ce qui s'est passé

Lorsque les développeurs utilisent Claude Code, l'assistant demande la permission avant d'exécuter des commandes shell. Si un utilisateur choisit d'approuver définitivement une commande spécifique, l'outil enregistre la chaîne de commande exacte, y compris tout secret intégré, dans un fichier de configuration local nommé .claude/settings.local.json. Bien que l'outil tente d'exclure ce fichier du contrôle de version en l'ajoutant aux exclusions git globales de l'utilisateur, il ne l'ajoute pas au fichier .gitignore du projet. Par conséquent, si le fichier est validé manuellement ou par l'agent lui-même, il devient partie intégrante de l'historique du dépôt.

Apiiro a scanné les dépôts GitHub publics et a identifié 104 185 copies de ce fichier de paramètres dans 103 617 dépôts. Parmi celles-ci, 1 122 fichiers contenaient au moins un secret, totalisant 1 379 identifiants uniques exposés. Les données divulguées incluent 379 mots de passe de base de données, 43 identifiants de connexion SSH pour des serveurs publics, 42 jetons pour des services comme GitHub et npm, ainsi que 23 clés AWS. Les chercheurs ont confirmé qu'une entreprise notifiée avait une clé active exposée via ce mécanisme.

L'exposition est persistante car la suppression du fichier de la branche actuelle ne l'efface pas de l'historique git ni des forks. Dans 539 des dépôts tracés, les commits listant Claude comme co-auteur ont modifié le fichier, suggérant que l'agent valide souvent ses propres modifications de configuration. De plus, 298 copies du fichier partagé .claude/settings.json, que les équipes valident intentionnellement, contenaient également des secrets. En incluant les versions historiques et les journaux de chat de l'agent, le nombre total de secrets exposés monte à 2 539 dans 1 994 dépôts.

Comment cela fonctionne

La vulnérabilité provient de la manière dont Claude Code gère l'approbation des commandes. Par défaut, il invite les utilisateurs avant d'exécuter des commandes shell. Lorsqu'un utilisateur sélectionne « Oui, et ne plus demander », le système crée une règle d'autorisation dans .claude/settings.local.json. Cette règle correspond aux futures commandes pour éviter des invites répétées. Si la commande approuvée est une chaîne exacte plutôt qu'un modèle, tout mot de passe ou jeton saisi dans cette commande est enregistré verbatim dans le fichier JSON.

Bien que Claude Code ajoute le fichier aux exclusions git globales de l'utilisateur lors de sa première création dans un dépôt, cette protection est locale à cette machine et cet utilisateur spécifiques. Elle ne se propage pas aux autres collaborateurs et ne protège pas contre les validations accidentelles. De plus, les outils standards de scan de secrets manquent souvent ces fuites. Lors de tests, gitleaks n'a signalé que 564 des 1 122 fichiers exposés, et TruffleHog en a signalé 643. Les deux outils ont entièrement manqué 215 fichiers car ils recherchent des formats de clés connus, alors que les mots de passe intégrés dans des commandes comme mysql -p apparaissent comme du texte ordinaire.

Détails clés

• Apiiro a trouvé 1 122 copies publiques de .claude/settings.local.json contenant au moins un secret.
• Les secrets exposés incluent 379 mots de passe de base de données, 43 connexions SSH et 23 clés AWS.
• Claude Code est le seul agent de codage parmi 16 examinés confirmé pour sauvegarder les commandes approuvées complètes dans les fichiers de projet par défaut.
• Les scanners standards comme gitleaks et TruffleHog n'ont pas détecté 215 des secrets exposés.
• Quatre rapports de bugs concernant ce comportement ont été fermés par un bot automatisé sans réponse d'Anthropic.
• Les secrets restent accessibles dans l'historique git et les forks même après la suppression du fichier de la branche principale.

Pourquoi c'est important

Pour les ingénieurs logiciels, cet incident met en évidence une lacune critique dans le modèle de sécurité des assistants de codage IA. Les développeurs supposent souvent que les fichiers de configuration locaux sont à l'abri de l'exposition publique, surtout lorsque les outils prétendent gérer les exclusions git. Cependant, la dépendance aux paramètres git globaux signifie que tout collaborateur qui valide le fichier, ou toute erreur dans la configuration locale, peut divulguer des données sensibles. Le fait que l'agent IA lui-même puisse valider ces fichiers exacerbe le risque, car les développeurs pourraient ne pas examiner chaque modification effectuée par l'assistant.

Les équipes de sécurité doivent désormais traiter les dossiers spécifiques aux agents et les fichiers de mémoire avec la même rigueur que les fichiers .env. L'échec des outils de scan standards à détecter les mots de passe intégrés dans les chaînes de commandes signifie que les pipelines CI/CD existants peuvent donner un faux sentiment de sécurité. Les organisations doivent mettre à jour leurs hooks pre-commit et leurs configurations de scan de secrets pour cibler spécifiquement ces nouveaux vecteurs, garantissant que les mots de passe dans les commandes sont signalés aux côtés des formats traditionnels de clés API.

Ce que vous pouvez faire

• Recherchez dans votre organisation GitHub les fichiers .claude/settings.local.json et .claude/settings.json, y compris dans l'historique git.
• Faites pivoter chaque mot de passe, jeton et clé qui a jamais été stocké dans ces fichiers avant de tenter un nettoyage.
• Exécutez git rm --cached .claude/settings.local.json et ajoutez le fichier au .gitignore de votre dépôt.
• Inspectez manuellement le fichier de paramètres local sur votre machine et supprimez toutes les règles contenant des secrets codés en dur.
• Utilisez des variables d'environnement (par exemple, $DB_URL) dans les commandes au lieu de saisir les secrets directement, afin que la règle sauvegardée référence le nom de la variable.
• Approuvez des modèles de commandes (par exemple, npm run:*) plutôt que des commandes exactes uniques pour empêcher la sauvegarde d'arguments spécifiques.