Claude Code a laissé fuiter 1379 secrets : des clés AWS et des mots de passe de bases de données dans des dépôts publics

Un scénario bien connu : une fonction pratique devient une faille parce que personne ne regarde ce qu’elle écrit exactement sur le disque. Cette fois, il s’agit de Claude Code. Selon les chercheurs d’Apiiro, les dépôts publics de GitHub hébergent 1122 copies du fichier de configuration de l’agent. Ils y ont découvert 1379 secrets : mots de passe de bases de données, jetons d’API, clés AWS et autres identifiants.

Comment les secrets se retrouvent dans le fichier de configuration

Claude Code demande une autorisation avant d’exécuter une commande dans le terminal. Lorsque vous cliquez sur « Toujours autoriser », la règle est enregistrée dans un fichier de configuration au sein du projet. Le problème, c’est qu’elle est conservée telle quelle, avec les arguments de la commande.

Imaginez : vous demandez à l’agent de se connecter à une base de données et exécutez une commande dont le mot de passe figure directement dans la ligne de commande. Ou vous lancez curl avec un jeton dans un en-tête. Vous accordez une autorisation permanente, et toute la ligne, mot de passe compris, se retrouve dans le fichier. Ensuite, les habitudes prennent le relais : git add, commit, push. Le fichier se trouve dans le dossier du projet, et beaucoup ignorent jusqu’à son existence et son contenu.

Le secret se retrouve donc dans un emplacement auquel personne ne pense, au lieu d’un fichier .env que tout le monde a depuis longtemps pris l’habitude d’ajouter à .gitignore. C’est un angle mort classique : les outils de protection et les pratiques des équipes ciblent les fichiers habituels contenant des secrets, pas la configuration d’un agent d’IA.

Pourquoi c’est plus grave qu’une fuite ordinaire

Des bots scrutent en permanence les dépôts publics de GitHub. Une clé AWS exposée dans un dépôt public est généralement exploitée en quelques minutes : minage de cryptomonnaies, spam, accès aux données. Même si vous supprimez le fichier au commit suivant, le secret reste dans l’historique Git.

Les chiffres d’Apiiro semblent ne représenter qu’un minimum : les chercheurs ont trouvé ce qui était visible dans les résultats de recherche, tandis que les dépôts privés et les forks ne font pas partie de l’échantillon. Par ailleurs, les mêmes risques concernent tout outil agentique qui mémorise les commandes autorisées : Cursor, Codex CLI, Gemini CLI et d’autres.

Que faire dès maintenant

Premièrement : vérifiez vos dépôts. Repérez le dossier de configuration de Claude Code et examinez la liste des commandes autorisées. Toute ligne contenant un mot de passe, un jeton ou une clé doit vous faire réagir.

Deuxièmement : si un secret a pu se retrouver dans un dépôt public, considérez-le comme compromis. Supprimer le fichier ne suffit pas : il faut révoquer la clé et en générer une nouvelle. Nettoyer l’historique Git est utile, mais ne garantit pas que personne n’en a déjà récupéré une copie.

Troisièmement : ajoutez le fichier de configuration locale de l’agent à .gitignore et intégrez un outil de détection des secrets aux étapes de pre-commit et à la CI. Gitleaks, TruffleHog ou la protection des push intégrée à GitHub permettent de détecter ce type de données avant leur publication.

Quatrièmement : ne transmettez pas de secrets dans la ligne de commande. Utilisez des variables d’environnement, des gestionnaires de secrets ou des jetons à courte durée de vie, afin que la règle d’autorisation ne contienne aucune donnée de valeur. Et ne cliquez pas sur « Toujours autoriser » pour des commandes comportant des arguments sensibles.

Limites

Notre source est ici une publication sur X renvoyant à une étude d’Apiiro ; nous n’avons pas consulté le rapport complet. On ignore combien des 1379 secrets étaient encore actifs, et combien avaient déjà été révoqués ou servaient à des tests. On ne sait pas non plus, à ce stade, si Anthropic modifiera ce comportement : par exemple, en masquant les arguments dans les règles enregistrées ou en avertissant du risque de les inclure dans un commit.

Mais la conclusion pratique ne dépend pas de ces détails. Les agents d’IA créent de nouveaux fichiers contenant des données annexes que les anciennes habitudes de sécurité ne prennent pas en compte. Vérifiez vos dépôts aujourd’hui, sans attendre la première facture d’AWS.