Résumé
Le Silverfort Une équipe de recherche a découvert que la manière dont Anthropic stocke les identifiants de l'interface de ligne de commande Claude Code sur macOS permet à n'importe quel processus exécuté avec les permissions de l'utilisateur de voler facilement les identifiants de son compte Anthropic, et par extension, ceux de tout serveur MCP connecté. Une simple lecture silencieuse permet de récupérer l'ensemble de ces identifiants, qu'un attaquant peut ensuite réutiliser depuis une autre machine pour usurper l'identité de l'utilisateur.
Le Trousseau d'accès macOS dispose d'un mécanisme de stockage sécurisé qui exige que l'utilisateur saisisse à nouveau son mot de passe ou une confirmation biométrique avant de transmettre une clé secrète à un processus demandeur. Claude Desktop utilise correctement ce mécanisme. Si un autre processus tente d'accéder aux informations d'identification stockées, macOS invite l'utilisateur à se réauthentifier. Ce n'est pas le cas de Claude Code CLI. Son implémentation permet à n'importe quel processus en mode utilisateur de récupérer les informations d'identification sans aucune demande de réauthentification ; nous reviendrons sur ce point plus en détail dans cet article.
Il ne s'agit pas techniquement d'une vulnérabilité, mais d'un défaut de conception, une faille de sécurité : les identifiants qui devraient nécessiter une réauthentification ne le font pas. Son exploitation ne requiert pas de technique sophistiquée autre que l'exécution de code avec les privilèges de l'utilisateur, ce qui est bien moins complexe qu'une élévation de privilèges. Ce défaut de conception affecte tout utilisateur macOS exécutant Claude Code CLI (et non les utilisateurs de Windows Desktop, ni ceux utilisant Windows/Linux, car ces derniers s'appuient sur un stockage de fichiers où les antivirus/EDR existants sont censés détecter toute altération).
En résumé : si un code malveillant s’exécute sous le compte d’un utilisateur, il peut lire discrètement les identifiants Claude, sans élévation de privilèges, sans demande de mot de passe ni alerte, et accéder latéralement aux serveurs MCP. Sur macOS, le Trousseau d’accès est plus sûr que le stockage de fichiers, mais comme l’interface de ligne de commande de Claude Code ignore l’étape de réauthentification, cet avantage disparaît. De plus, aucune heuristique antivirus existante ne détecte ce type d’accès, contrairement aux heuristiques d’accès aux fichiers sur d’autres plateformes. Si un terminal est compromis, un attaquant accède au compte Anthropic de l’utilisateur et à tous les serveurs MCP connectés. Il peut alors influencer tout ce que ces serveurs contrôlent : le code source de l’entreprise sur GitHub, sa base de connaissances sur Atlassian, ou d’autres connecteurs MCP sensibles.
Silverfort J'ai signalé cette découverte à Anthropic le 25 juin via HackerOne, conformément à sa pratique de divulgation responsable. Anthropic a rapidement répondu et, après discussion avec son équipe, a confirmé qu'elle travaillait à un renforcement du contrôle d'accès de l'élément Trousseau d'accès afin d'améliorer la sécurité et qu'elle considérait cette mesure comme « une modification de défense en profondeur… qui mérite d'être mise en œuvre ». Anthropic n'a pas émis d'objection. Silverfort publier la recherche.
Conseils aux défenseurs
En attendant que ce problème soit résolu, les organisations utilisant Claude Code CLI sur macOS doivent créer une alerte chaque fois que le même jeton est utilisé sur différentes machines. Au-delà des méthodes traditionnelles de détection et de réponse, les organisations devraient envisager une plateforme de sécurité des identités capable de contrôler l'utilisation d'identifiants statiques ou temporaires et de signaler l'utilisation d'un même jeton à partir de deux machines différentes, un indicateur fort d'utilisation d'identifiants volés. Les équipes de sécurité doivent surveiller tout accès anormal ou inattendu au Trousseau d'accès utilisé par l'interface de ligne de commande Claude Code. Les schémas d'accès inhabituels à ce magasin d'informations d'identification constituent un indicateur significatif de compromission potentielle et doivent être considérés comme un élément déclencheur d'une enquête.
Présentation
Les agents de codage IA possèdent désormais de véritables identifiants. Pour effectuer leur travail, ils se connectent et conservent un jeton sur la machine. Claude Code CLI Claude ne fait pas exception. Lorsque vous l'exécutez, il s'authentifie via un ensemble OAuth : un jeton d'accès temporaire et un jeton de rafraîchissement permanent. C'est ce dernier qui est préoccupant. Il peut être échangé contre de nouveaux jetons d'accès jusqu'à sa révocation ; il ne s'agit donc pas d'une session temporaire, mais d'un accès permanent au compte sur un ordinateur portable.
L'emplacement du fichier OAuth dépend de votre système d'exploitation. Sur deux des trois plateformes (Linux et Windows), il s'agit d'un simple fichier sur le disque. Sur macOS, il est stocké dans le Trousseau d'accès système – une solution logique, mais avec un inconvénient : par défaut, l'élément est lié au programme qui l'a créé, or, dans ce cas précis, il s'agit d'un outil de sécurité que n'importe quel processus peut exécuter. Le verrou est donc présent, mais il n'est jamais appliqué, et tout processus de votre compte obtient les jetons sans que l'utilisateur ait à saisir son mot de passe.
Nous allons suivre l'authentification Claude Code CLI sur les trois plateformes, examiner de près une faille de sécurité macOS, présenter une astuce simple pour réutiliser un bundle volé et terminer par la question que toute entreprise se posera : le nouveau Passerelle d'applications Claude Cela rend-il cela sans importance ? La réponse courte est non.
Les secrets dans un dossier, ça paraît pire, mais c'est celui qu'on peut regarder.
Sous Linux et Windows, les identifiants sont stockés dans un fichier JSON en clair, sans intervention du système de clés. Cette approche semble globalement moins sécurisée, mais la présence d'un fichier d'identifiants sur le disque est un problème que les équipes de sécurité savent déjà gérer. C'est une cible classique, et les outils de sécurité des terminaux, tels que les antivirus et les solutions EDR, peuvent détecter toute tentative d'accès à un fichier contenant des jetons. Il existe un emplacement connu pour mettre en place un contrôle et un élément concret pour déclencher une alerte. Sous macOS, ce filet de sécurité disparaît, comme nous le verrons.
La documentation de l'interface de ligne de commande Claude Code indique l'emplacement du fichier :
« Sous Linux, les identifiants sont stockés dans
~/.claude/.credentials.jsonavec le mode fichier 0600."« Sous Windows, les informations d'identification sont stockées dans
%USERPROFILE%\.claude\.credentials.jsonet hériter des contrôles d'accès de votre répertoire de profil utilisateur, qui restreint par défaut l'accès au fichier à votre compte utilisateur.
Un petit bémol : CLAUDE_CONFIG_DIR Ce fichier est déplacé ailleurs, de sorte que les règles de détection qui codent en dur le chemin littéral ne détecteront pas ces installations.
Ce fichier contient toutes les informations importantes : un jeton d’accès OAuth (sk-ant-oat…), un jeton d’actualisation à longue durée de vie (sk-ant-ort…), une date d’expiration et les étendues des jetons. Ce même emplacement stocke également les jetons OAuth du serveur MCP et les secrets des plugins que vous avez connectés. Le jeton d’actualisation est crucial, car sa simple lecture permet d’obtenir un accès permanent au compte. Sous Linux et Windows, voici quelques éléments à surveiller :
- Surveillance de l'intégrité des fichiers. Traitement
~/.claude/.credentials.json(Et l'CLAUDE_CONFIG_DIRvariante) comme objet sensible. L'alerte souhaitée est une lecture ou une ouverture par un processus autre que le binaire claude. Sous Linux, vous pouvez le faire avec une surveillance auditd (auditctl -w /home/*/.claude/.credentials.json -p rwa -k claude_creds) ou la télémétrie ouverte eBPF. Sous Windows, utilisez l'audit d'accès aux objets (ID d'événement 4663) avec une SACL ou la télémétrie de lecture de fichiers EDR. - Dérive des permissions. Le fichier Linux doit rester à l'emplacement indiqué.
0600Si cela devient lisible par un groupe ou par le monde entier, c'est en soi un signe d'alerte. - Signatures de contenu. Les préfixes sk-ant-oat (accès) et sk-ant-ort (actualisation) sont considérés comme des indicateurs d'authentification pour la protection contre la perte de données (DLP) et l'antivirus. Signalez-les dans les fichiers situés en dehors du répertoire de configuration, dans les archives, dans le presse-papiers et dans le trafic sortant. La présence du préfixe refresh-token est la plus grave.
- L'aspect lié à l'identité. Le meilleur signal ne provient pas du terminal. Un jeton qui apparaît d'abord sur un hôte, puis sur un autre, est un indicateur typique de vol d'identité. Soyez vigilant : si la même session OAuth réapparaît sur un nouvel appareil, un nouvel emplacement ou une nouvelle adresse IP peu après une lecture locale, c'est précisément à cela que sert une plateforme de protection contre les menaces d'identité.
Conservez le fichier d'accompagnement, ~/.claude.json, également sur votre radar. Ce n'est pas le magasin secret, mais il détient l'identité du compte (oauthAccount,userID), qui constitue l'autre moitié d'une séance de travail. Nous y reviendrons dans la section suivante.
Le verrou qui ne fonctionne pas : sur macOS, le Trousseau d’accès est une bonne idée, mais son implémentation doit être correcte.
macOS rompt avec ce modèle, l'interface de ligne de commande conservant ses identifiants dans le Trousseau d'accès plutôt que dans un .credentials.json fichier. La documentation est explicite :
« Sous macOS, les identifiants sont stockés dans le Trousseau d'accès macOS chiffré. »
C'est le bon réflexe. Un espace de stockage chiffré et protégé par le système d'exploitation est toujours préférable à un fichier plat. Cependant, la sécurité d'un élément du Trousseau d'accès dépend de la liste de contrôle d'accès (ACL) qui lui est associée, et c'est là que ce cas précis présente des faiblesses.
Claude Code CLI crée son élément Keychain en exécutant une commande shell. /usr/bin/security add-generic-passwordet ne transmet aucun argument de contrôle d'accès : ni -T pour faire confiance à une application spécifique, ni -A pour autoriser toutes les applications. L'élément hérite donc de la liste de contrôle d'accès (ACL) par défaut du Trousseau d'accès. La page de manuel security(1) de macOS explique le fonctionnement de cette liste par défaut :
« Par défaut, l’application qui crée un élément est autorisée à accéder à ses données sans avertissement. Vous pouvez supprimer cet accès par défaut en spécifiant explicitement un chemin d’accès vide à l’application : -T "". »
Sur ce chemin de code, l'application qui crée l'élément est /usr/bin/security lui-même. Le lecteur de confiance enregistré sur l'article est donc : /usr/bin/security, assis dans le apple-tool: la partition que macOS réserve aux outils signés par Apple. C'est ce comportement par défaut qui pose problème. /usr/bin/security est un outil en ligne de commande générique, signé par Apple, et tout processus exécuté sous votre compte peut l'appeler sans privilèges spéciaux. Une liste de contrôle d'accès (ACL) dont le seul lecteur de confiance est le security L'outil est satisfait par tout processus qui exécute le security L'outil, c'est-à-dire chaque processus sur la machine, est concerné. La liste de contrôle d'accès (ACL) est censée contrôler quel programme peut lire le secret. En pratique, elle ne contrôle rien, car n'importe quel programme peut le lire en demandant à un binaire standard d'effectuer la lecture.
Le résultat est une lecture silencieuse sur une seule ligne :
security find-generic-password -s "Claude Code-credentials" -a "$USER" -w
Pas de Touch ID, pas de saisie de mot de passe, pas d'élévation de privilèges. L'intégralité des informations d'identification au format JSON est renvoyée : le jeton d'accès, le jeton d'actualisation à longue durée de vie et tous les secrets MCP ou plugins qui partagent cet élément.
Anthropic le fait déjà correctement avec Claude Desktop, alors pourquoi pas Claude Code CLI ?
La preuve la plus flagrante qu'il s'agit d'un choix d'implémentation et non d'une limitation de macOS est qu'Anthropic le fait déjà correctement dans Claude Desktop. Claude Desktop fonctionne sur le même système d'exploitation, pour le même utilisateur, et protège le même type de secret. Il utilise pour cela Electron safeStorage, et sa conception mérite d'être détaillée, car elle diffère de celle de l'interface en ligne de commande (CLI). safeStorage Electron conserve une clé de chiffrement dans le Trousseau d'accès et stocke les jetons chiffrés dans un fichier sur le disque. La documentation d'Electron décrit comment cette clé est protégée :
« Les clés de chiffrement de votre application sont stockées dans l’accès au trousseau de manière à empêcher les autres applications de les charger sans l’intervention de l’utilisateur. »
L'élément du Trousseau d'accès contenant cette clé ne répertorie que l'application Claude signée dans sa liste de contrôle d'accès (ACL), et sa partition est associée à l'équipe de développement d'Anthropic. Par conséquent, une lecture de sécurité depuis n'importe quelle source est impossible. sinon, le mot de passe de connexion est demandé.Le texte chiffré sur le disque est inutile sans la clé, et la clé ne sera pas fournie sans cette invite.
Les deux interfaces semblent similaires, mais leur fonctionnement diffère considérablement. L'interface en ligne de commande (CLI) stocke les jetons dans le Trousseau d'accès avec une liste de contrôle d'accès (ACL) permettant à n'importe quel processus de les lire. Claude Desktop, quant à lui, ne stocke qu'une clé dans le Trousseau d'accès, l'associe à sa propre signature et conserve les jetons chiffrés dans un fichier inutilisable seul. Même système d'exploitation, même utilisateur, même type de secret : l'un peut être lu silencieusement par n'importe quel processus, tandis que l'autre requiert l'autorisation de l'utilisateur. La différence réside dans la manière dont l'élément du Trousseau d'accès est créé et dans ce qu'il protège.
Cause première: L'interface de ligne de commande (CLI) transmet la création d'éléments à /usr/bin/security Au lieu d'utiliser l'API native Keychain Services pour lier l'élément à la signature de code du binaire Claude (comme le fait déjà Claude Desktop), l'outil de sécurité ne peut pas lier un élément au programme qui l'a appelé. Seule l'API native le permet. En termes de vulnérabilités, cela correspond aux CWE-732 (attribution incorrecte des permissions pour une ressource critique) et CWE-522 (informations d'identification insuffisamment protégées).
Reconstruire la session sans toucher à un seul fichier de configuration
La lecture du jeton ne représente que la moitié du processus d'usurpation d'identité. Pour se faire passer pour la victime, l'interface de ligne de commande Claude Code doit également savoir qui est connecté, information généralement stockée dans le répertoire courant. oauthAccount bloc à l'intérieur ~/.claude.jsonLa solution de facilité serait de voler ce fichier également. Il existe une méthode plus propre qui laisse beaucoup moins de traces, et il est important de l'examiner, car l'explication qui semble plausible est erronée.
La recette, sur la machine de l'attaquant :
1. Exportez le jeton d'accès volé et exécutez Claude une seule fois :
export ANTHROPIC_API_KEY=<access-token>
claude
2. Sortez, puis unset ANTHROPIC_API_KEY.
3. Cachez le paquet volé dans votre propre porte-clés :
security add-generic-password -U -s "Claude Code-credentials" -a "$USER" -T /usr/bin/security -w 'PASTE_THE_JSON_HERE'
4. courir claude Vous êtes maintenant connecté(e) en tant que victime.
Voici l'aspect contre-intuitif : ce n'est pas la variable d'environnement qui vous connecte. Un vol sk-ant-oat… La valeur placée dans ANTHROPIC_API_KEY est envoyée comme en-tête X-Api-Key, conformément à la documentation sur la priorité d'authentification de l'interface de ligne de commande Claude Code. Or, cet en-tête et le type de jeton sont incorrects, car un jeton d'accès OAuth n'est pas une clé API de console. Il n'authentifie en aucun cas les appels de modèle.
Alors, à quoi sert l'exportation ? L'ordre des opérations est crucial. La première exécution, avec le jeton d'accès volé exporté, permet d'inscrire l'identité du compte de la victime dans le fichier ~/.claude.json, évitant ainsi à l'attaquant d'avoir à le copier. Ensuite, vous supprimez la variable et placez l'ensemble des données, jeton d'actualisation inclus, dans le Trousseau d'accès. La documentation décrit la procédure. unset ANTHROPIC_API_KEY Pour « revenir à votre abonnement », la dernière exécution s'effectue comme suit : elle s'authentifie auprès du trousseau Keychain, qui sert d'identifiant d'abonnement. Le jeton d'actualisation à longue durée de vie de ce dernier génère en permanence de nouveaux jetons d'accès. Cet identifiant est le moins prioritaire de la liste, mais aussi le plus durable.
Pourquoi les systèmes de sécurité devraient-ils s'en préoccuper ? Parce que l'intérêt principal de cette méthode réside dans sa faible empreinte. Une simple lecture silencieuse du Trousseau d'accès remplace le transfert de plusieurs fichiers, et moins de fichiers copiés sur la machine source signifie moins d'indicateurs pour la détection d'exfiltration. Sur macOS, il est impossible d'attendre un événement de fichier, puisqu'aucun fichier n'est présent. La lecture s'effectue au sein d'un processus ; c'est donc ce processus qu'il faut surveiller.
Toute la chaîne, du début à la fin
Une fois les deux éléments réunis, l'attaque est rapide. Côté victime, tout s'exécute comme pour un utilisateur ordinaire, sans invite ni privilège ; côté attaquant, il s'agit simplement d'une relecture.
Voici ce même flux sous forme de preuve de concept, exécuté de bout en bout :
La passerelle d'applications Claude ne résoudra-t-elle pas ce problème ?
Réponse courte : non. Nous avons déployé la passerelle, configuré notre propre code Claude dessus et exécuté exactement le même vol. Cela a fonctionné.
Il est important de préciser ce qu'est la passerelle, car son rôle est plus restreint que son nom ne le suggère. Il ne s'agit pas d'une couche de sécurité supplémentaire pour votre configuration Claude habituelle. C'est un outil de routage permettant de diriger Claude Code vers un point de terminaison de modèle spécifique, exécuté ou choisi par votre organisation, en dehors du chemin par défaut d'Anthropic : infrastructure sur site, Microsoft Foundry, Amazon Bedrock, Google Cloud ou un point de terminaison Anthropic dédié. Les raisons observées sont classiques : règles de résidence des données et de conformité, fournisseur cloud privilégié ou déploiement local. Si votre organisation ne correspond pas à cette description, la passerelle n'a jamais fait partie de votre configuration et l'élément du Trousseau d'accès est exposé comme décrit dans la suite de cet article.
Il est légitime de se demander à quoi sert la passerelle, car elle n'est pas inutile. Les développeurs se connectent via l'authentification unique d'entreprise, les sessions durent environ une heure et la révocation est gérée par le fournisseur d'identité. Ainsi, lorsqu'une organisation désactive un utilisateur, son accès à la passerelle est interrompu au cours de la session. La clé amont, la clé API Claude ou les identifiants cloud ne sont pas stockés sur l'ordinateur portable. C'est ce que signifie l'annonce :
« Aucun secret bien gardé ne reste sur les machines des développeurs. »
Il est crucial de lire cette phrase au pied de la lettre, car elle concerne la clé d'amont, et non le vol. Ce qui se trouve encore dans le Trousseau d'accès sous la passerelle est une authentification de rafraîchissement. Son utilisation peut être limitée à la passerelle, mais c'est là le problème : un attaquant qui s'en empare et se connecte à la passerelle en tant qu'utilisateur peut créer de nouvelles sessions tant que ce compte reste actif. La durée de session d'une heure n'empêche jamais le voleur d'agir. Seule l'organisation peut le détecter et désactiver l'utilisateur, et une lecture silencieuse du Trousseau d'accès ne permet pas d'y parvenir. L'expression « pas de secrets à longue durée de vie » se transforme en réalité en un accès permanent pour quiconque lit l'élément.
Nous avons donc configuré une passerelle, connecté Claude à celle-ci et répété l'attaque décrite dans la section précédente. Le contenu du trousseau est resté inchangé. Le même script Python d'une seule ligne a extrait les identifiants sans aucune intervention de notre part, et nous les avons copiés sur une seconde machine.
Cette fois, nous n'avons même pas eu besoin de l'initialisation supplémentaire de la section précédente, ni d'un second fichier provenant de la victime. L'adresse de la passerelle est déjà incluse dans les identifiants volés. La valeur stockée dans l'élément « Claude Code-credentials Keychain » contient plus que les jetons : elle enregistre également la passerelle à laquelle la victime était connectée. Ainsi, une simple lecture silencieuse nous fournit à la fois les clés et l'adresse de la passerelle.
Cela signifie qu'il n'y a rien de plus à extraire du disque de la victime. Nous créons la configuration sur la machine de l'attaquant, à l'emplacement suivant :
/Bibliothèque/Support applicatif/ClaudeCode/managed-settings.json
et pointez-le vers l'URL de la passerelle que nous venons de lire dans les informations d'identification volées :
{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}
La création de ce fichier ne constitue pas un obstacle. Anthropic qualifie d'ailleurs les paramètres gérés de « contrôle côté client, et non de barrière de sécurité », permettant ainsi à un attaquant de les créer à sa guise. Nous chargeons ensuite les identifiants volés et lançons Claude Code. Aucune étape supplémentaire n'est nécessaire pour recréer l'identité de la victime. Les identifiants contiennent le jeton, ce jeton authentifie la passerelle, et la passerelle exécute la session en tant que victime, avec ses droits d'accès.
La passerelle présente toutefois un obstacle qu'un attaquant distant ne pourrait franchir. Claude Code ne communiquera pas avec une passerelle via une adresse publique.
« À l’adresse /login, Claude Code exige que le nom d’hôte ou l’adresse IP de la passerelle ne soit résolu qu’en adresses privées : RFC 1918, link-local, CGNAT 100.64.0.0/10, IPv6 ULA fc00::/7 ou bouclage pour le développement local. Pour une passerelle hébergée par vos soins, toute adresse publique est rejetée. »
L'identifiant volé ne fonctionne donc que depuis un point d'accès à la passerelle privée. Cela peut paraître insurmontable, mais il faut tenir compte du modèle de menace. On suppose déjà que l'attaquant se connecte en tant qu'utilisateur sur la machine de la victime, laquelle se trouve déjà au sein de ce réseau. Accéder à une adresse privée depuis cette machine est la partie la plus simple. Il s'agit d'une friction, et non d'une barrière.
Voici un bilan honnête. La passerelle présente d'autres avantages : elle empêche la clé d'accès principale de se trouver sur l'ordinateur portable et offre à l'organisation un point d'arrêt centralisé via le fournisseur d'identité (IdP), même si ce dernier n'est utile qu'une fois le vol constaté. En revanche, elle ne corrige pas la faille de sécurité décrite dans cet article. Les identifiants sont toujours enregistrés dans le même élément du Trousseau d'accès, cet élément reste accessible à tous les processus sans avertissement, et des identifiants d'actualisation volés continuent de fonctionner contre la passerelle jusqu'à la désactivation du compte.
Le contrôle du réseau est un détour, pas un arrêt. Et pour la grande majorité des utilisateurs, qui n'ont jamais besoin d'accéder à la passerelle, rien ne change.
Que doit faire un défenseur immédiatement ?
- macOS : tant que la liste de contrôle d'accès (ACL) de l'élément n'est pas liée à la signature Claude, le point de détection est le processus, et non un fichier. Le signal est un appel à `/usr/bin/security find-generic-password` dont la chaîne de service est « Claude Code-credentials » et qui utilise l'option `-w` pour afficher le secret. Détectez cet appel via l'exécution des processus ou la télémétrie d'Endpoint Security, et utilisez la traçabilité des processus pour réduire les faux positifs : les lectures légitimes remontent au binaire Claude, il faut donc les analyser en premier lieu, tandis que les lectures suspectes proviennent d'une commande shell, d'un éditeur ou d'un hôte d'extensions, ou d'un script d'installation de dépendances. Surveillez également `add-generic-password` pour ce même service, car c'est ainsi qu'un paquet volé est installé sur une autre machine. Considérez ces alertes comme un contrôle compensatoire.
- Linux et Windows : surveillance de l’intégrité des fichiers et DLP sur .credentials.json, alertes de dérive des permissions et signatures de contenu sur les préfixes sk-ant-oat et sk-ant-ort.
- Partout : corrélez les lectures du magasin d’identifiants avec le trafic sortant inhabituel et surveillez le plan d’identité pour détecter la réutilisation d’un même jeton sur plusieurs hôtes. En cas de suspicion, effectuez une rotation. Une seule lecture génère un jeton d’actualisation à longue durée de vie ; par conséquent, un événement de lecture crédible nécessite une déconnexion et une reconnexion, ainsi qu’une rotation des clés de console, et non un simple nettoyage du point de terminaison.
- La véritable solution, sans risque, revient à Anthropic : créer l’élément Keychain de l’interface de ligne de commande via l’API native, lié à la signature de code du binaire Claude. C’est le modèle déjà implémenté dans Claude Desktop.
La bonne nouvelle, c'est que la partie la plus complexe est déjà résolue au sein même du code source d'Anthropic. L'interface en ligne de commande n'a pas besoin d'un nouveau modèle de sécurité : elle utilise celui déjà en place.
Calendrier de divulgation
25 juin, 3h46 UTC. Le chercheur soumet le rapport comprenant les étapes de reproduction, l'impact et trois captures d'écran.
25 juin, 4h05 UTC. Anthropic le clôture comme informatif seulement 19 minutes plus tard, l'excluant du champ d'application sous « Stockage local des informations d'identification, de la configuration et des journaux de Claude Code », et déclare que les processus du même utilisateur sont entièrement dignes de confiance, de sorte que les ACL du trousseau par processus n'ajoutent aucune limite significative.
2 juillet, 11h12 UTC. Le chercheur demande une réévaluation humaine, soutient que la fermeture a été associée à la mauvaise exclusion (il s'agit d'une erreur de configuration de l'ACL du trousseau, et non du stockage local, et Desktop fonctionne correctement sur le même système d'exploitation), joint la vidéo de preuve de concept et annonce la rédaction d'un rapport de défense avec une offre de coordination de la divulgation.
2 juillet, 11h14 UTC. Anthropic accuse réception de la demande de réévaluation et indique qu'elle procédera à un examen interne, confirme que la discussion publique est acceptable puisque le rapport est clos, et demande à consulter une ébauche au préalable.
22 juillet. Le chercheur partage la version finale de l'article de blog pour relecture avant publication, comme l'avait demandé Anthropic, et note qu'elle inclut désormais une analyse visant à déterminer si la passerelle d'applications Claude atténue ou non la faille.
24 juillet. Anthropic a finalisé son analyse, n'a relevé aucun problème factuel ni aucune correction demandée, et a validé la publication du rapport. Sa classification reste inchangée : Anthropic précise qu'elle suit désormais de près le renforcement du contrôle d'accès de l'élément « Trousseau » comme une amélioration de sécurité en profondeur pertinente, même si elle ne le considère pas comme une vulnérabilité dans son modèle de menaces.
