Sandbox de Claude Cowork : une évasion root contestée et le débat de l'exécution locale

De quoi s’agit-il ?

Le 1er juillet 2026, la société de sécurité Armadin a publié une chaîne d’attaque qui obtient un shell root à l’intérieur de la sandbox Linux isolée que Claude Cowork, d’Anthropic, utilise pour exécuter du code non fiable, ainsi qu’une seconde étape qui supprime les restrictions de sortie réseau censées contenir cette sandbox. La publication a été reprise le jour même par SiliconANGLE, SC Media, GBHackers et d’autres. La nuance essentielle tient au cadrage : Armadin a signalé la chaîne à Anthropic plus tôt dans l’année, et Anthropic a refusé de la traiter comme un problème de sécurité, au motif que sa mise en œuvre suppose que l’attaquant dispose déjà d’une exécution de code locale sur la machine hôte. Aucun CVE n’a été attribué. Il ne s’agit donc pas d’une faille exploitable à distance, mais d’une faiblesse divulguée dans une couche de défense, et d’un désaccord réel sur ce qu’une sandbox est supposée protéger face à un attaquant déjà présent sur le poste.

Comment ça marche

La chaîne, telle que décrite publiquement, comporte deux volets conceptuels. Le premier est un classique point d’entrée par DLL sideloading (MITRE ATT&CK T1574.002) : le binaire de bureau signé de Claude résout une bibliothèque système depuis son propre répertoire d’application avant de se rabattre sur la vraie copie système, si bien qu’un fichier déposé à côté, portant le nom et la fonction exportée attendus, s’exécute au sein d’un processus légitimement signé. Cette étape exige que l’attaquant puisse déjà écrire des fichiers et exécuter du code sur l’hôte — précisément la condition préalable qu’invoque Anthropic.

Le second volet est le plus instructif pour ceux qui conçoivent des agents. La sandbox est provisionnée par un service local privilégié auquel l’application de bureau parle via un canal inter-processus. L’un des paramètres qui contrôlent la configuration d’une session était accordé sans validation : un indicateur censé forcer la création d’un utilisateur neuf et non privilégié pouvait au contraire être basculé pour réutiliser un compte nommé arbitraire, et le service honorait une requête désignant le superutilisateur sans la vérifier. Résultat : un shell root dans le conteneur, au lieu de l’utilisateur restreint prévu par la conception. Une lacune connexe permettait à l’appelant de désactiver le filtrage de sortie censé empêcher la sandbox de contacter des hôtes arbitraires. Nous décrivons délibérément la forme de la faille plutôt que de reproduire les paramètres, car la leçon utile est architecturale, pas une recette.

Pourquoi c’est important

Le désaccord est le cœur du sujet. La position d’Anthropic — une évasion de sandbox conditionnée à une exécution de code locale préexistante n’est pas une vulnérabilité — est défendable et courante : si l’attaquant exécute déjà du code sous votre identité, il peut déjà lire vos fichiers et vos clés, la sandbox n’a donc jamais été votre dernière ligne de défense. Le contre-argument implicite d’Armadin relève de la défense en profondeur : la proposition de valeur même de Cowork est d’exécuter du contenu non fiable, et une couche de confinement qui passe de non privilégié à root et de réseau restreint à non restreint via un unique indicateur non validé est une frontière plus faible que ce que la conception laisse entendre. Les deux peuvent être vraies simultanément. Ce qui compte pour quiconque livre un agent capable d’exécuter du code, c’est que le service auxiliaire privilégié qui provisionne votre sandbox fait lui-même partie de la surface d’attaque, et que faire confiance à des paramètres venus d’un appelant moins privilégié recrée un motif de « député confus » vieux de plusieurs décennies au cœur d’un runtime d’IA tout neuf. L’angle du binaire signé compte aussi : les attaquants recherchent l’exécution au sein d’un processus de confiance signé pour l’évasion, et les applications d’IA de bureau sont désormais des hôtes de grande valeur, car elles détiennent des clés d’API, des identifiants cloud et l’accès à tout ce à quoi l’agent est raccordé.

Défenses

Pour les équipes qui construisent ou exploitent des sandbox d’agents, traitez le service local de provisionnement comme une frontière de sécurité et validez chaque paramètre qu’il reçoit de l’application, en particulier tout ce qui sélectionne un utilisateur, un niveau de privilège ou une politique réseau ; une demande sollicitant root doit être rejetée d’emblée, pas honorée. Supposez que la sandbox sera parfois franchie et ajoutez des couches qui y survivent : comptes hôtes à moindre privilège, filtrage de sortie appliqué hors du conteneur et hors d’atteinte de l’appelant, et surveillance d’un processus de sandbox qui se met soudain à tourner sous root ou à joindre un hôte inattendu. Durcissez contre le DLL sideloading en résolvant les bibliothèques système depuis des chemins système fixes, en activant un ordre de recherche sûr et en signant puis contrôlant l’intégrité du répertoire d’application, afin qu’un fichier déposé à côté d’un binaire signé soit détecté. Pour les utilisateurs finaux, l’enseignement reste le même : maintenez à jour et exempts de code non fiable les postes qui exécutent des applications d’agent, car pour cette classe de problème, l’hôte est l’ancre de confiance. Si vous déployez Claude Cowork en entreprise, appliquez des contrôles endpoint qui détectent l’exécution de code locale et les écritures non autorisées dans les répertoires d’application, puisque c’est la condition préalable dont dépend toute la chaîne.

Statut

Divulguée par Armadin le 1er juillet 2026 après un signalement privé à Anthropic plus tôt dans l’année. Anthropic a répondu qu’elle ne considère pas la chaîne comme un problème de sécurité, l’exploitation exigeant une exécution de code locale préexistante sur l’hôte ; aucun CVE n’a été attribué et aucun correctif n’a été annoncé.

Élément	Détail
Divulgation	Publication Armadin, 1er juillet 2026
Produit	Sandbox de Claude Cowork (VM Linux sur hôte Windows)
Point d’entrée	DLL sideloading dans un binaire de bureau signé (T1574.002)
Élévation	Paramètre de provisionnement non validé → root dans la sandbox ; contournement du filtrage de sortie
Condition préalable	L’attaquant dispose déjà d’une exécution de code locale sur l’hôte
Position de l’éditeur	Non traité comme un problème de sécurité ; pas de CVE, pas de correctif annoncé