Apiiro a recensé des dizaines de milliers de copies publiques d’un fichier de configuration de Claude Code sur GitHub, dont plus d’un millier contiennent des secrets exploitables. En cause, une fonctionnalité pensée pour accélérer le travail quotidien, qui mémorise la commande approuvée sans distinguer un identifiant de connexion d’un argument anodin.
Un fichier de confiance qui mémorise aussi les secrets
Quand un développeur répond « Yes, and don’t ask again » à une demande d’exécution, Claude Code enregistre la règle dans .claude/settings.local.json, à la racine du projet. Si la règle porte sur une commande exacte plutôt que sur un motif générique, tout argument saisi dans cette commande, y compris un mot de passe ou un jeton d’API, est écrit en clair dans ce fichier. L’outil l’ajoute aux exclusions Git globales de la machine qui l’a créé, mais pas au .gitignore du dépôt : la protection ne voyage donc pas avec le code. Le rapprochement avec la gestion propre des variables d’environnement et des secrets s’impose ici : un identifiant qui transite par une commande shell plutôt que par un gestionnaire dédié reste exposé au premier faux pas.
L’ampleur du problème selon Apiiro
La société de sécurité a recensé plus de 104 000 copies de ce fichier dans plus de 103 000 dépôts publics. Parmi elles, 1 122 contiennent au moins un secret exploitable, pour un total de 1 379 secrets distincts. En intégrant l’historique Git, les forks dupliqués et un second fichier de configuration, .claude/settings.json, le total grimpe à 2 539 secrets répartis sur 1 994 dépôts et 63 organisations.
| Catégorie de secret | Volume constaté | Risque principal |
|---|---|---|
| Mots de passe de base de données | 379 | Accès direct à des données de production |
| Jetons (GitHub, GitLab, npm) | 42 | Publication ou modification de code au nom d’un compte |
| Connexions SSH vers serveurs publics | 43 | Prise de contrôle d’une machine exposée |
| Clés AWS | 23 | Accès à l’infrastructure cloud du compte visé |
Une clé cloud de niveau administrateur appartenant à un éditeur de bases de données et le mot de passe propriétaire d’une base de dossiers médicaux figurent parmi les cas cités. Les chercheurs n’ont pas vérifié systématiquement si chaque secret restait actif, mais une entreprise notifiée a confirmé qu’une de ses clés fonctionnait toujours.
Pourquoi les scanners classiques passent à côté
Sur les 1 122 fichiers contenant un secret, gitleaks en a repéré 564 et TruffleHog 643 ; 215 ont échappé aux deux, un secret noyé dans une ligne de commande ne ressemblant pas toujours à une clé API standard. Apiiro recommande de traiter les dossiers d’agents, .claude/ comme .cursor/, comme des emplacements à risque au même titre qu’un fichier .env, et de muscler en conséquence les scanners pré-commit et CI déjà présents dans la panoplie d’outils en ligne de commande du poste de développement.
Sur 1 105 dépôts où un commit porte Claude comme co-auteur, 539 montrent une modification automatique de ce fichier de configuration par l’agent lui-même.
Comment corriger la configuration dès maintenant
L’ordre des opérations compte : révoquer les identifiants exposés avant de nettoyer le dépôt, pas après, car un historique Git purgé ne retire rien de ce que des robots ont déjà pu indexer.
# 1. Retirer le fichier du suivi Git sans le supprimer du disque
git rm --cached .claude/settings.local.json
# 2. L'ajouter au .gitignore du projet, pas seulement à l'exclusion globale
echo ".claude/settings.local.json" >> .gitignore
# 3. Vérifier qu'aucune règle approuvée ne porte une commande complète avec secret
grep -n "Bearer\|password\|API_KEY" .claude/settings.local.json
git rm --cached ne nettoie pas l’historique : tout secret déjà commité reste lisible dans les anciens commits et les forks existants. La rotation immédiate du secret reste la seule protection fiable.Ce qu’il faut retenir
- La fonction « don’t ask again » de Claude Code peut écrire un secret en clair dans un fichier de projet non protégé par défaut au niveau du dépôt.
- Plus de 1 300 secrets exploitables ont été recensés dans des dépôts publics, dont des accès base de données, SSH et cloud.
- Les scanners de secrets classiques manquent près d’un cas sur cinq lorsque l’identifiant est noyé dans une commande.
- La correction passe par la rotation des identifiants avant tout nettoyage du dépôt, puis par l’ajout du fichier au
.gitignoredu projet.
Sur les projets suivis au quotidien, ce fichier de configuration d’agent est traité exactement comme un fichier d’environnement : il n’entre jamais dans un commit, point final. L’habitude de répondre « don’t ask again » pour gagner quelques secondes a un coût qui ne se voit qu’au moment où un dépôt passe en public. Un gestionnaire de secrets couplé à des règles d’approbation fondées sur des motifs plutôt que sur des commandes exactes règle le problème à la source, sans renoncer au confort que ces agents apportent par ailleurs — voir à ce sujet le retour d’expérience sur les agents éditoriaux en production. — Simon Janvier
Pour aller plus loin : le rapport complet d’Apiiro relayé par The Hacker News.
