23 juillet 2026, Claude Cowork sortait de sa VM sur Mac, fichiers hôtes exposés, le contournement d’Anthropic intrigue

Des chercheurs d’Accomplish AI ont décrit le 23 juillet 2026 une faiblesse touchant Claude Cowork, l’outil agentique d’Anthropic capable d’exécuter des tâches dans une machine virtuelle locale sur Mac. Leur démonstration montre qu’une session censée rester confinée pouvait accéder à des fichiers de l’ordinateur hôte, dont des clés SSH et des identifiants cloud. Le scénario, baptisé SharedRoot, ne reposait pas sur une demande de permission visible par l’utilisateur, mais sur une chaîne d’évasion combinant une faille Linux et un partage de fichiers trop permissif.

Accomplish AI décrit une évasion de Claude Cowork sur Mac

Le cas mis en lumière par Accomplish AI concerne le mode local de Claude Cowork, intégré à l’écosystème Claude pour automatiser des actions sur un poste de travail. Sur Mac, ce mode repose sur une machine virtuelle Linux chargée d’exécuter les opérations demandées à l’agent. Le principe vise à isoler l’environnement de travail, afin que l’outil n’accède qu’aux éléments explicitement partagés avec lui.

Selon les chercheurs, cette isolation n’a pas résisté à leur test. Ils indiquent avoir connecté un seul dossier à une session fraîche, puis envoyé un message court à l’agent. La session aurait alors quitté le périmètre attendu pour atteindre des fichiers situés ailleurs sur le Mac, sans alerte système ni fenêtre de validation. La démonstration visait notamment des éléments sensibles, comme des clés SSH et des jetons utilisés pour des services cloud.

Le nom SharedRoot résume la mécanique observée: l’agent obtenait des droits élevés dans l’environnement invité, puis profitait du partage de fichiers entre la VM et l’hôte. Pour un utilisateur non spécialiste, la distinction entre machine virtuelle, dossier partagé et compte macOS peut sembler technique. Pour une équipe de sécurité, elle conditionne pourtant le niveau de confiance accordé à un agent capable de lire, modifier ou générer des fichiers.

L’affaire attire l’attention parce que ces outils sont conçus pour agir avec autonomie. Un assistant limité à une conversation n’a pas le même impact qu’un agent autorisé à manipuler un projet local, lancer des commandes ou préparer des fichiers de configuration. Dans le cas présent, le risque ne venait pas seulement de la réponse produite par le modèle, mais de l’environnement d’exécution placé autour de lui.

CVE-2026-46331 ouvre l’accès root dans la VM Linux

La chaîne technique décrite par les chercheurs s’appuie sur CVE-2026-46331, une vulnérabilité du noyau Linux surnommée pedit COW. Cette faille, associée à un score de gravité proche de 8 sur 10, permettait une élévation de privilèges dans la machine virtuelle. L’agent partait d’une session utilisateur, puis gagnait des droits root dans le système invité.

Le point central réside dans la combinaison entre cette élévation de privilèges et le mécanisme de partage utilisé par la VM. Le montage VirtioFS donnait accès au système de fichiers de l’hôte. Ce montage devait être contrôlé, avec un accès réservé à root dans l’environnement invité. Dès lors que l’agent obtenait root dans la VM, cette barrière devenait insuffisante pour protéger les données du Mac.

Les chercheurs décrivent un accès possible au répertoire racine de l’hôte, avec les droits du compte utilisateur connecté côté macOS. Cela signifie qu’un attaquant exploitant la chaîne pouvait lire ou écrire dans des emplacements accessibles à cette session. Les fichiers visés dans la démonstration incluaient des clés SSH, des identifiants de fournisseurs cloud et d’autres secrets souvent stockés sur les machines de développeurs.

Ce scénario souligne une limite classique des bacs à sable locaux. Une machine virtuelle protège efficacement si les frontières avec l’hôte sont réduites et strictement filtrées. Quand un partage large et inscriptible expose le système de fichiers, la sécurité dépend fortement de l’absence de faille dans l’invité. Une seule vulnérabilité noyau peut transformer un environnement isolé en point d’entrée vers le poste principal.

Anthropic bascule Claude Cowork vers l’exécution cloud

Après le signalement, Anthropic aurait classé le rapport comme informatif, sans publier de correctif direct visant précisément la chaîne SharedRoot. La version diffusée ensuite modifie pourtant le comportement par défaut de Claude Cowork: l’outil privilégie désormais l’exécution cloud. Cette orientation écarte le chemin d’évasion local décrit par les chercheurs, car la VM vulnérable n’est plus le point d’exécution standard sur le Mac de l’utilisateur.

Cette réponse peut être lue comme un contournement opérationnel plutôt qu’une correction du mécanisme initial. Pour les utilisateurs qui acceptent l’exécution distante, le risque lié au montage local disparaît du poste. Pour ceux qui conservent des sessions locales, la question demeure plus sensible. Le mode local garde un intérêt fort dans les entreprises attachées à la confidentialité, à la latence réduite ou au contrôle des environnements de développement.

Des publications relayées autour de l’incident évoquent environ 500 000 utilisateurs macOS potentiellement concernés avant le changement de configuration par défaut. Ce chiffre doit être interprété avec prudence, faute de communication chiffrée détaillée de l’éditeur. Il donne néanmoins un ordre de grandeur de l’enjeu, car Claude Cowork s’adresse à des profils susceptibles de manipuler du code, des accès serveurs et des ressources cloud.

Les mesures de réduction du risque citées par les chercheurs passent par la désactivation des espaces de noms non privilégiés, la limitation stricte des dossiers partagés et des protections de montage renforcées pour le démon Cowork. Ces réglages demandent des compétences techniques. Ils montrent que l’usage local d’un agent IA ne peut plus être traité comme une simple option de confort dans une application grand public.

Les équipes Mac doivent durcir les agents IA locaux

Pour les administrateurs macOS, l’incident renforce une règle déjà connue dans la sécurité des postes: un outil capable d’automatiser des actions doit être évalué comme un logiciel à privilèges, pas comme une simple interface conversationnelle. Les agents IA multiplient les interactions avec le système, les dépôts de code, les fichiers de configuration et les gestionnaires d’identifiants.

La première réponse consiste à cartographier les usages. Une entreprise doit savoir qui exécute Claude Cowork en local, quels dossiers sont partagés, quels secrets se trouvent sur les machines et quelles politiques empêchent l’accès non autorisé aux clés de production. Les environnements de développement concentrent souvent des accès sensibles: certificats, variables d’environnement, jetons d’API, profils cloud ou scripts de déploiement.

Le second volet relève de la séparation des périmètres. Les organisations peuvent créer des comptes dédiés, restreindre les répertoires exposés, interdire les montages larges et surveiller les accès anormaux aux fichiers sensibles. Les équipes de sécurité doivent aussi vérifier les paramètres liés aux espaces de noms Linux dans les VM utilisées par ces outils. La promesse d’un bac à sable ne remplace pas un contrôle indépendant de sa configuration.

Cette affaire arrive au moment où les éditeurs accélèrent l’intégration d’agents dans les postes de travail. Le confort est réel: analyse de code, rédaction de scripts, manipulation de documents, lancement de tâches répétitives. Le coût potentiel l’est aussi, surtout quand l’agent opère au contact direct des secrets numériques. Les prochaines versions devront fournir davantage d’indicateurs visibles sur les fichiers accessibles, les montages actifs et les permissions accordées à chaque session locale.