Claude Code fait fuiter des mots de passe sur GitHub : Apiiro a trouvé des secrets dans 1 100 fichiers de configuration

Vous lancez Claude Code, il propose d'exécuter une commande shell et, pour ne pas être dérangé, vous cliquez sur « Yes, and don't ask again ». Pratique. Mais, avec cette commodité, vous risquez d'inscrire discrètement dans le projet le mot de passe de votre base de données. C'est précisément ce qui, selon les chercheurs d'Apiiro, se produit dans des milliers de dépôts.

Comment le secret arrive dans le fichier

Le mécanisme est simple. Lorsque l'utilisateur autorise une commande de façon permanente, Claude Code enregistre cette décision sous forme de règle dans le fichier local .claude/settings.local.json. Parfois, la règle est écrite sous forme de motif. Mais souvent, la commande est inscrite telle quelle dans le fichier, avec tout ce qu'elle contient.

Imaginez un exemple typique : vous demandez à l'agent de vérifier la base de données, et il lance psql avec une chaîne de connexion où le mot de passe figure en clair. Ou il exécute un curl avec un jeton d'API dans l'en-tête. Vous approuvez la commande « pour toujours », et toute la ligne avec le secret se retrouve dans le fichier JSON.

Tant que le fichier reste sur votre machine, c'est tolérable (si la machine n'est pas piratée). Anthropic indique dans sa documentation que ce fichier est ajouté au .gitignore global du développeur. Mais le .gitignore global vit sur votre ordinateur, pas dans le dépôt. Si vous clonez le projet sur une autre machine, transformez le dossier en dépôt plus tard ou travaillez en équipe, la protection disparaît. Apiiro précise aussi que, dans de nombreux cas, Claude Code commite lui-même les modifications de ce fichier sans intervention de l'utilisateur.

L'ampleur du problème et pourquoi les scanners ne suffisent pas

Les analystes d'Apiiro ont trouvé plus de 100 000 cas où le fichier local de paramètres de Claude Code s'est retrouvé dans un dépôt public GitHub. La plupart sont inoffensifs. Mais dans environ 1 100 fichiers appartenant à 63 organisations, de véritables secrets ont été découverts : jetons d'API, mots de passe de bases de données, clés privées et même identifiants root.

Supprimer le fichier du dépôt ne suffit pas. Si le projet a déjà été forké, les secrets restent dans les forks. Une clé doit donc être considérée comme compromise dès qu'elle est apparue ne serait-ce qu'une fois dans un commit public.

Autre point fâcheux : les scanners de secrets habituels ne garantissent aucune protection. Sur les ~1 100 secrets trouvés, 215 ont échappé à la fois à gitleaks et à TruffleHog. La raison est claire : le secret est intégré à la chaîne de la commande, et non présenté dans le format habituel KEY=value.

L'historique n'incite pas non plus à la confiance. Le problème avait été signalé dans des rapports de bugs dès août 2025. D'autres rapports mentionnaient que le fichier n'était parfois pas ajouté au .gitignore et que des commandes sensibles pouvaient être écrites dans un autre fichier, lui totalement non protégé. Toutes ces demandes ont été closes sans action après 60 jours d'inactivité.

Ce week-end, dans un fil de discussion sur Hacker News, Boris Cherny, de l'équipe Claude Code, a répondu que l'équipe « étudie ce qui peut être fait ». Selon lui, ces fichiers ne devraient presque jamais finir dans git, et les cas problématiques surviennent lorsque les fichiers ont été créés et commités manuellement. Il a conseillé l'auto mode, où des classificateurs décident eux-mêmes quelles demandes d'autorisation sont routinières. Lorsqu'un autre utilisateur a fait remarquer que, même en auto mode, des commandes sensibles peuvent être enregistrées dans les paramètres, Cherny a reconnu : « bonne trouvaille ». L'équipe envisage un scanner de secrets intégré à Claude Code comme une possibilité pour l'avenir.

Que faire dès aujourd'hui

Inutile d'attendre un correctif. Voici une courte liste pour les développeurs et les tech leads :

• Ajoutez .claude/settings.local.json au .gitignore du dépôt lui-même, et pas seulement au .gitignore global.
• Vérifiez l'historique : git log --all -- .claude/settings.local.json. Si le fichier a déjà été commité, ouvrez-le et cherchez des mots de passe et des jetons.
• Réémettez tout ce que vous trouvez. Supprimer le fichier ne révoque pas la clé, surtout s'il existe des forks.
• N'écrivez pas de secrets dans les commandes que vous approuvez « pour toujours ». Utilisez des variables d'environnement ou un gestionnaire de secrets.
• Activez un scanner de secrets en pre-commit et ne le considérez pas comme une panacée : les 215 oublis montrent qu'un seul outil ne suffit pas.
• Examinez le fichier de paramètres lui-même avant de pousser. C'est un simple JSON, on y repère facilement ce qui est en trop.

Ce n'est pas la première fois qu'un agent d'IA dévoile des données par inadvertance. Le mois dernier, Meta a suspendu la fonction de partage dans son agent Muse : des chercheurs avaient découvert que les liens vers les contenus partagés étaient faciles à deviner.

La leçon vaut pour tous les outils agentiques. Tout ce que l'agent mémorise pour votre confort devient un fichier de plus que quelqu'un peut publier par erreur. Traitez les configurations d'agents avec la même rigueur que le .env.