La commande /copy de Claude Code laissait les réponses dans un fichier temporaire lisible par tous

De quoi s’agit-il ?

Le 25 juin 2026, un avis de sécurité (GHSA-4vp2-6q8c-pvq2) a décrit une faille locale dans Claude Code, l’agent de codage en ligne de commande d’Anthropic. La commande /copy — qui copie la dernière réponse de l’assistant dans le presse-papiers — écrivait d’abord cette réponse à un chemin fixe sur le disque : /tmp/claude/response.md. Le fichier était créé lisible par tous (mode 0644) dans un répertoire traversable par tous (0755), sans isolation par utilisateur, sans nom aléatoire et sans protection contre les liens symboliques.

La conséquence est un problème classique des postes multi-utilisateurs, transposé dans un outil d’IA. Sur un hôte partagé, n’importe quel autre utilisateur local pouvait lire ce fichier — or la réponse de l’assistant contient couramment des secrets, des clés d’API, des jetons ou du code propriétaire collé dans la conversation. La faille a été corrigée dans la version 2.1.128, publiée fin juin 2026, et touche toutes les versions de 2.1.59 jusqu’à ce correctif. Elle a été signalée par un chercheur externe via le programme de divulgation coordonnée d’Anthropic.

Comment ça marche

Il n’y a ici aucun exploit inédit, et c’est précisément l’intérêt. Le défaut réside dans deux règles de gestion de fichiers vieilles de plusieurs décennies, que la fonctionnalité a ignorées.

Comportement                  Ce que /copy faisait       Pourquoi c'est dangereux
----------------------------  -------------------------  -----------------------------
Choix du chemin               /tmp/claude/response.md    Prévisible — tout utilisateur
                              codé en dur                local sait où lire / déposer
Permissions du fichier        0644 (lisible par tous)    Les autres lisent le contenu
Permissions du répertoire     0755 (traversable)         Les autres entrent et listent
Gestion des liens             aucune                     Suit le lien d'un attaquant
Isolation par UID             aucune                     Tous partagent un seul chemin

Deux risques distincts en découlent. Le premier est la divulgation : le fichier étant lisible par tous, un utilisateur local non privilégié peut simplement lire la dernière réponse d’un utilisateur privilégié qui a lancé /copy. Le second est une écriture par lien symbolique : le chemin étant statique et prévisible, un utilisateur local peut pré-créer le répertoire et déposer un lien symbolique au nom de fichier attendu, pointant vers un autre fichier du disque. Lorsque le processus privilégié écrit ensuite la réponse, il suit le lien et écrase la cible choisie par l’attaquant avec le texte de la réponse. Les deux exigent un second utilisateur non privilégié sur la même machine et un utilisateur privilégié invoquant réellement la commande — il s’agit donc d’un problème local et multi-locataire, pas distant. Les classes de faiblesse sont les familières CWE-377 (fichier temporaire non sécurisé), CWE-59 (suivi de lien) et CWE-200 (exposition d’information).

Pourquoi c’est important

Les assistants de codage IA sont adoptés plus vite que ne s’accumule leur historique de sécurité, et il est tentant de se concentrer uniquement sur les modes de défaillance exotiques — injection de prompt, empoisonnement d’outils, évasion de bac à sable. Cette faille est un rappel utile : les primitives de sécurité d’avant l’IA s’appliquent toujours, et une CLI qui tourne sur des portables de développeurs, des runners d’intégration continue, des hôtes bastion et des serveurs de build partagés hérite de chaque piège classique d’escalade locale que les outils Unix ordinaires ont mis trente ans à éviter.

L’ampleur du rayon d’impact dépend de l’endroit où l’outil s’exécute. Sur un portable mono-utilisateur, le risque pratique est faible. Sur un serveur de build partagé, un hôte de rebond multi-utilisateurs ou une image de conteneur où coexistent plusieurs identités de service, un fichier lisible par tous contenant en clair le texte d’une réponse d’assistant est une fuite d’identifiants qui ne demande qu’à se produire — et la variante par lien symbolique transforme un problème de lecture en une primitive d’écriture limitée. Cela se combine mal avec la vague plus large de découvertes d’exposition locale de Claude Code de ce cycle, dont un problème antérieur où l’outil Read atteignait l’environnement du runner en CI. Les fichiers temporaires qu’écrivent les agents font partie de la surface d’attaque, au même titre que la gestion des liens symboliques autour des flux d’approbation.

Défenses

Le correctif principal est la mise à jour ; le reste relève d’une hygiène qui se généralise à toute CLI d’IA que vous exécutez.

1. Mettez à jour Claude Code en 2.1.128 ou ultérieure. Les utilisateurs en mise à jour automatique l’ont déjà reçue ; vérifiez avec claude --version et fixez un plancher dans les installations gérées.
2. Traitez les hôtes partagés comme hostiles pour les outils d’IA. Préférez des machines par utilisateur ou des bacs à sable par UID. Sur les systèmes multi-utilisateurs, évitez les commandes d’assistant qui matérialisent les réponses sur disque, sauf si vous contrôlez l’umask et le répertoire.
3. Durcissez la gestion des fichiers temporaires au niveau OS. Activez fs.protected_symlinks=1 (par défaut sur Linux moderne) pour empêcher les processus de suivre des liens dans des répertoires qu’ils ne possèdent pas ; utilisez un répertoire temporaire par utilisateur via XDG_RUNTIME_DIR ou un TMPDIR privé plutôt qu’un sous-arbre /tmp partagé.
4. Pour les développeurs d’outils : créez les fichiers temporaires correctement. Utilisez des API de type mkstemp (nom aléatoire, O_EXCL, mode 0600), écrivez dans un répertoire par UID, et jamais dans un chemin partagé fixe. Préférez un transfert du presse-papiers en mémoire plutôt qu’un passage par le disque.
5. Scannez votre arbre de dépendances. Cette faille est suivie dans les bases de vulnérabilités contre le paquet npm @anthropic-ai/claude-code ; les outils de dependency-scanning et de SCA signaleront désormais les versions affectées, alors intégrez les paquets de CLI d’IA au même pipeline que le reste.
6. Faites tourner tout ce qui a pu transiter par le fichier. Si /copy a été exécuté sur une machine partagée avec une version vulnérable installée, considérez comme potentiellement exposés les secrets apparus dans ces réponses et renouvelez-les.

Statut

Élément	Référence	Date	Notes
Avis de sécurité	GHSA-4vp2-6q8c-pvq2	2026-06-25	Fichier temporaire non sécurisé + écriture par lien dans /copy
Enregistrement CVE	CVE-2026-46406 (NVD)	2026-06	CVSS 3.1 6.1 (moyen) ; CWE-377, CWE-59, CWE-200
Versions affectées	GitLab Advisory DB	—	2.1.59 jusqu’à, mais non incluse, 2.1.128
Version corrigée	Claude Code 2.1.128	2026-06-29	Mise à jour automatique déployée ; les updaters manuels doivent migrer

La leçon n’est pas que les outils de codage IA sont uniquement peu sûrs — c’est qu’ils sont des logiciels tournant sur de vraies machines, et que les aspects ennuyeux de la sécurité logicielle n’ont pas cessé de s’appliquer quand l’outil a appris à écrire du code. Chemins temporaires prévisibles, modes lisibles par tous et liens symboliques non protégés sont exactement les bugs qu’une CLI mature ne devrait jamais livrer, quoi qu’elle fasse avec un modèle de langage en dessous.