Cybersécurité

Claude Code a exposé des mots de passe dans 1 122 fichiers GitHub publics

Susan Hill
Ajoutez-nous sur Google

Anthropic’s Claude Code demande une autorisation avant d’exécuter la plupart des commandes shell, et propose notamment de répondre « Oui, et ne plus me le demander ». Si vous choisissez cette option pour une commande contenant un mot de passe, par exemple les identifiants de connexion à une base de données, Claude Code peut enregistrer la commande entière — mot de passe compris — dans un fichier de paramètres en texte brut, au sein de votre projet. Des chercheurs en sécurité ont découvert des milliers de ces mots de passe et clés dans des dépôts de code publics sur GitHub, accessibles à tous.

Si vous utilisez Claude Code, le fichier à rechercher s’appelle settings.local.json. Il se trouve dans un dossier caché, .claude, à la racine du dépôt, et accompagne le projet partout où il est copié, à moins que vous ne preniez des mesures pour l’en empêcher. Le comportement est le même dans tous les pays où l’outil est disponible. Changer ses habitudes ne prend qu’une minute, tandis qu’un mot de passe divulgué est bien plus long à faire oublier : supprimer le fichier ne l’efface ni de l’historique Git ni des forks d’autres personnes.

La société spécialisée dans la sécurité logicielle Apiiro a passé au crible GitHub et découvert 104 185 exemplaires du fichier dans 103 617 dépôts, selon ses recherches rapportées par The Hacker News. Environ 1,1 %, soit 1 122 exemplaires, contiennent au moins un secret, pour un total de 1 379 identifiants différents. Plus d’un tiers permettraient d’accéder directement à une base de données, dont 379 mots de passe de bases de données. Le lot comprend aussi 43 identifiants SSH pour des serveurs publics, 42 jetons pour GitHub, GitLab et npm, ainsi que 23 clés Amazon Web Services.

Les propriétaires de ces dépôts ne sont pas tous des amateurs. Apiiro a rattaché les fichiers à 63 organisations, principalement des éditeurs de logiciels de toutes tailles. Parmi les cas les plus graves figurent la clé cloud de niveau administrateur d’un fournisseur de bases de données, ainsi que le mot de passe propriétaire d’une base de données de dossiers médicaux. Les anciennes versions du fichier présentes dans l’historique Git contiennent 734 secrets supplémentaires répartis dans 509 dépôts, et 211 forks de 74 dépôts reprennent les mêmes secrets que les dépôts d’origine. En ajoutant le fichier de paramètres partagé que les équipes valident volontairement dans le dépôt et les journaux de conversations enregistrés par les agents, le total atteint 2 539 secrets dans 1 994 dépôts.

Claude Code essaie bien de soustraire le fichier au contrôle de version. La documentation d’Anthropic sur les paramètres indique que, lors de la première création du fichier par l’outil, une règle est ajoutée à la liste globale des exclusions Git de l’utilisateur, afin que Git l’ignore sur cet ordinateur. Cette règle ne suit jamais le projet sur l’ordinateur d’un collègue, un serveur de compilation ou une nouvelle machine, et elle ne change rien si le fichier a déjà été ajouté au dépôt. Dans 539 des 1 105 dépôts examinés par les chercheurs, un commit mentionnant Claude comme coauteur a modifié le fichier, ce qui laisse penser que l’agent le valide souvent lui-même. Parmi les 16 agents de programmation dont Apiiro a comparé la documentation, Claude Code est le seul dont il est confirmé qu’il enregistre par défaut la commande approuvée dans son intégralité dans un fichier du projet.

Les protections habituelles en laissent passer une bonne partie. Apiiro a lancé deux outils open source populaires de détection des secrets, gitleaks et TruffleHog, sur chaque exemplaire : gitleaks a signalé 564 des 1 122 fichiers, TruffleHog en a repéré 643, et 215 ont échappé aux deux outils. La plupart des secrets manqués étaient des mots de passe saisis après PGPASSWORD=, sshpass -p ou mysql -p, qui ressemblent à des mots ordinaires pour un outil cherchant des formats de clés connus.

Ces résultats sont à prendre avec certaines réserves. Apiiro vend des outils de sécurité pour le développement assisté par l’IA : cette recherche fait donc aussi office d’argument commercial. L’entreprise n’a pas vérifié si les identifiants étaient toujours valides, même si une société qu’elle a alertée a confirmé que sa clé était encore active. Une valeur était considérée comme un secret si elle correspondait à un format de clé connu ou si elle figurait à côté de l’adresse d’un serveur public et qu’un évaluateur IA le confirmait, ce qui laisse une marge d’erreur et de faux positifs. Apiiro précise également que le nombre de commits attribués à Claude comme coauteur ne prouve pas que celui-ci a introduit chaque identifiant exposé. Et GitHub n’est que la partie visible du problème : le fichier est un simple JSON dans le dossier du projet et peut donc aussi se retrouver dans un paquet npm, une image Docker, une archive zip ou un dossier synchronisé.

Les chercheurs recommandent d’abord de renouveler les identifiants : changez chaque mot de passe, jeton et clé que le fichier a pu contenir avant de vous attaquer au nettoyage, car un secret qui a été rendu public est compromis, que vous réécriviez ou non l’historique. Cessez ensuite de suivre le fichier avec git rm –cached, ajoutez-le au fichier .gitignore du dépôt lui-même, puis ouvrez /permissions dans Claude Code pour supprimer toute règle enregistrée contenant un secret. En faisant référence aux identifiants via des variables d’environnement, une règle enregistrée stockera un nom tel que $DB_URL plutôt que le mot de passe. Et approuver des modèles plutôt que des commandes ponctuelles permet d’éviter que des arguments littéraux se retrouvent dans le fichier.

Des utilisateurs avaient déjà signalé le problème. Un rapport de bug déposé le 11 août 2025 indiquait que les commandes approuvées contenant des clés API et des jetons étaient enregistrées mot pour mot dans settings.local.json. Un bot automatisé l’a ensuite fermé avec le statut « not planned », le 3 janvier, après 60 jours sans activité. Apiiro, qui a publié ses conclusions le 6 novembre, affirme que les quatre signalements connexes qu’il cite ont tous été fermés par le même bot, le plus récent le 6 novembre, sans réponse d’Anthropic. Au 2 novembre, chaque fichier exposé découvert était toujours présent sur la branche principale de son dépôt ; dans la moitié des cas, il s’y trouvait depuis au moins 217 jours.

Ni The Hacker News ni Apiiro ne font état d’une réponse d’Anthropic, et le comportement documenté n’a pas changé : la prochaine fois que vous choisirez « ne plus demander » pour une commande dans laquelle vous avez saisi un mot de passe, celui-ci sera lui aussi enregistré.

Étiquettes: , , , , ,

Ajoutez-nous sur Google

Discussion

Il y a 0 commentaire.