Évasion du sandbox Cowork : un RPC signé qui faisait confiance aux privilèges du client

De quoi s’agit-il ?

Les 2 et 3 juillet 2026, plusieurs médias de sécurité ont relayé une analyse de Nick McClendon (Armadin) décrivant une évasion complète du sandbox Linux embarqué dans Claude Cowork, le produit de bureau d’Anthropic destiné aux profils non techniques. La chaîne permet à un attaquant disposant déjà d’une exécution de code sur l’hôte d’obtenir un shell root à l’intérieur du sandbox de l’agent, de désactiver le filtrage réseau et de s’échapper vers les espaces de noms de la VM hôte. Selon ces mêmes sources, la découverte a été signalée à Anthropic le 20 mars 2026 et validée sur la version 1.9255.2.0 de Claude Desktop pour Windows. Ceci est une analyse de conception, pas un mode opératoire actionnable.

Le point notable n’est pas qu’un sandbox ait cédé — les sandbox cèdent — mais comment. Le canal de contrôle qui pilote le sandbox authentifiait qui appelait tout en faisant confiance à ce que l’appelant demandait. Cette confusion entre identité et autorisation est la leçon réutilisable pour quiconque construit un runtime d’agent IA.

Comment ça marche

Sous Windows, Cowork exécute Claude Code dans une VM Ubuntu isolée par Hyper-V, provisionnée via le Host Compute Service. L’isolation est en couches : un service Local System (CoworkVMService) expose un serveur JSON-RPC sur un named pipe, et n’accepte que les appelants dont le binaire porte une signature Authenticode valide de « Anthropic, PBC ». Dans la VM, le travail s’exécute sous un espace de noms bubblewrap, avec un utilisateur non privilégié propre à la session, derrière un filtre seccomp et un proxy de sortie restreint par domaine.

Les chercheurs ont d’abord tenté de forger la signature, sans succès — WinVerifyTrust a tenu. Plutôt que de casser le contrôle d’identité, ils l’ont donc satisfait. Comme le binaire signé claude.exe résolvait une bibliothèque système depuis son propre répertoire avant le chemin système, une bibliothèque sosie placée à côté de lui a exécuté du code attaquant à l’intérieur du processus signé et de confiance — un DLL search-order hijack classique (MITRE ATT&CK T1574.002). L’appelant héritait alors de la confiance de signature d’Anthropic et pouvait dialoguer légitimement avec le pipe.

L’élévation est venue du contrat RPC lui-même. Les journaux du service sur le disque révélaient le schéma des méthodes, dont un appel spawn avec des paramètres fournis par le client. Deux d’entre eux étaient acceptés tels quels par le démon invité. Un indicateur de reprise de session, censé se rattacher à une session existante, court-circuitait le chemin qui crée un utilisateur non privilégié — une requête nommant un utilisateur existant arbitraire (y compris le superutilisateur) s’exécutait donc sous cet utilisateur, avec toutes les capacités et un profil non confiné. Un paramètre de domaines réglé sur un joker transformait le proxy de sortie restrictif en proxy ouvert. Avec un processus root dans l’espace de noms, un simple nsenter sur le PID 1 permettait ensuite de sortir vers les espaces de noms mount, PID et réseau de la VM hôte, exposant des fichiers comme /etc/shadow. Aucun payload n’est reproduit ici ; c’est le mécanisme qui compte.

Pourquoi c’est important

Chaque couche de protection a fonctionné comme prévu, et la boîte s’est quand même ouverte, parce qu’un serveur privilégié a délégué des décisions de sécurité — quel utilisateur exécuter, quels domaines joindre — à des valeurs contrôlées par le client. Verrouiller un canal de contrôle par signature prouve l’identité de l’appelant ; cela ne dit rien de la légitimité d’une requête donnée. C’est le même problème de frontière de confiance que derrière les frontières de privilège du harnais d’agent et les fuites via l’environnement dans les agents de code, et c’est précisément pourquoi le cadrage zero-trust pour agents traite le sandbox comme un contrôle parmi d’autres, et non comme le contrôle.

La position d’Anthropic, selon les sources, est qu’il ne s’agit pas d’une vulnérabilité de sécurité car elle présuppose une exécution de code locale sur l’hôte, hors de son modèle de menace. C’est une ligne défendable pour un logiciel classique — mais elle mérite d’être examinée pour les outils d’agents IA en particulier, car ces outils existent pour exécuter du code non fiable et suivre des instructions non fiables. « Nécessite une exécution locale » est une frontière plus faible quand exécuter du contenu influencé par l’attaquant est la fonction même du produit.

Défenses

Pour les concepteurs, la règle durable est que l’authentification n’est pas l’autorisation : un appelant signé ou autorisé doit toujours voir chaque méthode et chaque paramètre vérifiés côté serveur, et les décisions de privilège ou de sortie ne doivent jamais provenir de champs fournis par le client. Les chemins de reprise/rattachement doivent redériver l’identité depuis l’état du serveur, pas depuis un nom fourni par l’appelant. Durcissez aussi le socle du contrôle d’identité — une porte par signature ne vaut que par l’intégrité du code du processus signé, donc imposez un ordre de recherche de DLL sûr et l’intégrité des applications empaquetées pour qu’un binaire de confiance ne puisse charger une bibliothèque non fiable.

Pour les exploitants, considérez tout environnement qui exécute du code généré par IA comme non fiable, et empilez des contrôles au-delà du sandbox : restreignez les applications signées autorisées à s’exécuter (par exemple via les règles d’applications empaquetées AppLocker), surveillez les chargements de bibliothèques anormaux comme une DLL système chargée hors de System32 (Sysmon Event ID 7), gardez les runtimes d’agents à l’écart des réseaux de production et des coffres à secrets, et alertez sur les changements de privilège ou les sorties réseau inattendus depuis les sandbox d’agents. Partez du principe que des évasions seront trouvées et dimensionnez le rayon d’impact en conséquence.

Statut

Élément	Détail
Divulgation	Nick McClendon (Armadin) ; signalé à Anthropic le 20 mars 2026 ; publications publiques les 2–3 juillet 2026
Nature	Élévation de privilèges et évasion du sandbox via DLL search-order hijack + RPC de contrôle faisant confiance aux privilèges/domaines fournis par le client
Validé sur	Claude Desktop pour Windows build 1.9255.2.0
Prérequis	Exécution de code locale sur l’hôte
Position de l’éditeur	Classée par Anthropic comme non-vulnérabilité de sécurité (exécution locale considérée comme prérequis) ; aucun CVE attribué à ce jour
Classe	Authentification ≠ autorisation ; contrôle d’accès défaillant dans le plan de contrôle d’un agent

Les détails reflètent la reprise par des tiers de la recherche d’Armadin, testée sur une version Windows précise. Les positions de l’éditeur et les internes du produit évoluent — vérifiez sur la version courante d’un déploiement avant d’en tirer des conclusions.