Claude Code : 1 122 fichiers exposent des secrets sur GitHub

Claude Code enregistre parfois mots de passe et clés d'API en clair : Apiiro en a trouvé 1 122 copies publiques sur GitHub.
Des mots de passe et des clés d’API traînent aujourd’hui dans des dépôts GitHub publics. Ils étaient saisis dans des commandes validées avec Claude Code. En effet, n’importe qui peut les lire. L’assistant de programmation d’Anthropic en est la source, à cause d’une option pourtant très pratique.
L’éditeur de sécurité logicielle Apiiro a récemment tiré la sonnette d’alarme. Selon lui, 1 122 copies publiques de ce fichier de paramètres sont accessibles sur GitHub. Chacune peut donc contenir des identifiants sensibles.
Comment Claude Code enregistre vos secrets
Le mécanisme est simple. D’abord, lorsque Claude Code veut exécuter une commande, il demande l’accord de l’utilisateur. Plusieurs choix sont proposés, notamment Yes, and don’t ask again.
Cette option évite d’être sollicité à chaque exécution. Ainsi, pour s’en souvenir, l’outil inscrit la commande approuvée dans un fichier de paramètres propre au projet. Or il la copie mot pour mot.
Autrement dit, tout ce qui figurait dans la commande est conservé. Un mot de passe ou une clé d’API collé dans la commande est donc écrit en clair dans le fichier. En effet, rien n’est masqué ni remplacé.
Le problème apparaît ensuite. Ce fichier se trouve dans le dossier du projet. Il suit donc le code lorsque celui-ci est versé sur GitHub.
Ce que révèle l’analyse d’Apiiro
Apiiro a recherché ces fichiers de paramètres dans les dépôts publics. Le décompte atteint 1 122 copies accessibles à tous. Ce chiffre montre ainsi que le cas n’est pas isolé.
Chaque copie représente un projet dont l’auteur a sans doute validé une commande sans y penser. Ensuite, il a publié son travail comme d’habitude. En effet, rien dans ce geste ne laisse penser qu’un secret vient d’être enregistré.
Les conséquences dépendent de la nature des identifiants. Par exemple, une clé d’API peut ouvrir l’accès à un service payant ou à des données internes. Un mot de passe peut également donner la main sur un serveur, une base de données ou un compte cloud.
De plus, les dépôts publics sont scrutés en permanence. Des outils automatisés parcourent GitHub pour y repérer des secrets oubliés. Un identifiant exposé peut donc être exploité très vite.
Un risque facile à sous-estimer
Plusieurs raisons expliquent pourquoi ce type de fuite passe inaperçu. D’abord, le fichier est généré par l’outil, et non écrit à la main. Le développeur ne pense donc pas à le relire avant un commit.
Ensuite, le réflexe de gain de temps joue contre la prudence. Cliquer sur « ne plus demander » semble anodin. Pourtant, ce clic transforme une approbation ponctuelle en une trace permanente.
Par ailleurs, les assistants de code IA s’intègrent de plus en plus dans les flux de travail quotidiens. Ils exécutent des commandes, modifient des fichiers et créent leurs propres fichiers de configuration. Or ces fichiers échappent souvent aux contrôles habituels de l’équipe.
Enfin, un secret publié sur GitHub reste dangereux même après suppression. L’historique Git conserve en effet les anciennes versions. Les copies et les clones peuvent aussi subsister ailleurs.
Recommandations pour les utilisateurs de Claude Code
Si vous utilisez Claude Code, quelques réflexes limitent fortement le risque. Voici les principaux.
- Vérifiez vos dépôts. Ouvrez le fichier de paramètres du projet. Cherchez-y des mots de passe, des jetons ou des clés d’API dans les commandes enregistrées.
- Révoquez les secrets exposés. Si un identifiant a été publié, considérez-le comme compromis. Changez-le immédiatement, sans attendre de constater un abus.
- Ne supprimez pas seulement le fichier. En effet, l’historique Git garde la trace des anciennes versions. La rotation des identifiants reste donc indispensable.
- Évitez les secrets dans les commandes. Privilégiez les variables d’environnement ou un gestionnaire de secrets. La commande ne contient alors aucune valeur sensible.
- Soyez prudent avec l’option permanente. N’utilisez Yes, and don’t ask again que pour des commandes sans donnée confidentielle.
- Excluez le fichier du suivi Git. Ajoutez-le à votre fichier d’exclusion. Ainsi, il ne partira pas sur GitHub par erreur.
- Activez l’analyse des secrets. Des outils dédiés détectent les identifiants avant ou après un push. Ils vous alertent donc rapidement.
Ce qu’il faut retenir
L’alerte d’Apiiro rappelle une règle simple : un outil qui mémorise vos actions mémorise aussi vos erreurs. Ainsi, avec Claude Code, une commande approuvée de façon permanente peut contenir un secret écrit en clair. Ce secret risque ensuite de finir sur GitHub avec le reste du projet.
Le chiffre de 1 122 copies publiques doit donc servir d’avertissement. Les développeurs ont intérêt à auditer leurs dépôts dès maintenant. Ils doivent également renouveler tout identifiant exposé et garder leurs secrets hors des lignes de commande.
Source : Claude Code's “Don't Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub