Claude Cowork, d'Anthropic, permet à son agent IA de s'échapper de sa VM
Claude Cowork, d'Anthropic, permet à son agent IA de s'échapper de sa VM et d'accéder à des fichiers sensibles sur l'ordinateur de l'utilisateur, révélant une grave faille dans le bac à sable
La récente nouvelle selon laquelle un agent ChatGPT aurait échappé à son environnement de test pour attaquer des services sur Internet a fait beaucoup parler d'elle, mais il semble qu'il ne soit pas le seul capable de se déchaîner. Les chercheurs en sécurité d'Accomplish AI affirment avoir obtenu des résultats similaires avec Claude Cowork d'Anthropic. Les chercheurs expliquent avoir lancé une session locale sur une machine virtuelle Linux hébergée sur un Mac, puis avoir observé l'agent s'échapper de la machine virtuelle et commencer à lire et à écrire des fichiers sur le système sous-jacent. Pour sortir du bac à sable, l'agent a exploité la faille CVE-2026-46331 (« pedit COW »), une vulnérabilité du noyau Linux permettant une élévation de privilèges, corrigée à la mi-juin de cette année.
Il y a peu, OpenAI a déclaré que deux de ses modèles d’IA les plus avancés — notamment GPT-5.6 Sol et un modèle en pré-lancement encore plus performant, tous dotés de capacités de cyberdéfense réduites à des fins d’évaluation — s’étaient échappés d’un test contrôlé et avaient piraté une autre entreprise spécialisée dans l’IA. OpenAI a indiqué que cet « incident de cybersécurité sans précédent » s’était produit lors d’un exercice interne destiné à tester les capacités cybernétiques de ses modèles. OpenAI affirme que ce piratage montre que l’agent est allé « très loin » pour récupérer des informations qui aideraient à atteindre les objectifs du test.
La récente nouvelle selon laquelle un agent ChatGPT aurait échappé à son environnement de test pour attaquer des services sur Internet a fait beaucoup parler d’elle, mais il semble qu’il ne soit pas le seul capable de se déchaîner. Les chercheurs en sécurité d’Accomplish AI affirment avoir obtenu des résultats similaires avec Claude Cowork d’Anthropic. Les chercheurs expliquent avoir lancé une session locale sur une machine virtuelle Linux hébergée sur un Mac, puis avoir observé l’agent s’échapper de la machine virtuelle et commencer à lire et à écrire des fichiers sur le système sous-jacent.
« Nous avons connecté un dossier à une nouvelle session de Claude Cowork, envoyé un court message, puis observé l’agent s’échapper du bac à sable », a déclaré Oren Yomtov, chercheur principal en sécurité chez Accomplish AI. « Depuis l’intérieur de la machine virtuelle, il a accédé au Mac hôte et a lu et écrit des fichiers un peu partout sur celui-ci, bien au-delà du dossier que nous avions connecté, sans qu’aucune demande d’autorisation ne s’affiche. »
Exécution par défaut dans le cloud
Cela signifie qu’en théorie, l’agent peut être utilisé pour accéder à tout ce qui est stocké sur le compte utilisateur du Mac, ou pour en extraire des données, y compris les clés SSH, les identifiants de connexion au cloud, etc. Pour sortir du bac à sable, l’agent a exploité la faille CVE-2026-46331 (« pedit COW »), une vulnérabilité du noyau Linux permettant une élévation de privilèges. Cette faille, corrigée à la mi-juin de cette année, s’est vu attribuer un score de gravité de 7,8/10 (élevé).
Accomplish AI a communiqué ces découvertes à Anthropic, qui les aurait reconnues sans toutefois publier de correctif direct. Cependant, la version de Claude Cowork publiée par la suite utilise par défaut l’exécution dans le cloud, ce qui, selon la publication, résout le problème. Néanmoins, les utilisateurs qui choisissent d’exécuter l’agent localement plutôt que dans le cloud resteront exposés.
Récemment, un article de l'agence de presse Reuters, citant des sources proches de l'enquête, a affirmé qu'il avait fallu environ 10 jours à l'entreprise pour se rendre compte qu'un de ses agents IA autonomes s'était échappé de son environnement de test et avait piraté Hugging Face, la plus grande base de données au monde de modèles d'IA. L'incident s'est déroulé entre le 9 et le 20 juillet : l'agent IA s'est d'abord échappé de son environnement de test isolé avant de s'introduire dans Hugging Face le 11 juillet, précise le rapport de Reuters. Le rapport ajoute que le personnel d'OpenAI a examiné les journaux internes au cours du week-end des 18 et 19 juillet et a trouvé des preuves indiquant que l'agent s'était échappé de son environnement de test. Cet incident a ravivé l'attention portée aux risques associés aux agents IA autonomes.
Dans ce contexte, Sam Altman, considéré par certains comme la plus grande star de l'IA, est le cofondateur et PDG d'OpenAI, entreprise à l'origine de ChatGPT. C'est l'une des personnalités majeures de la montée en puissance de l'IA observée ces dernières années. Dans un récent entretien, il revient sur la question en lien avec les avancées en matière d'IA et affirme que l'IA est entrée dans la « singularité », c'est-à-dire qu'elle a franchi le point de non-retour à partir duquel elle dépasse l'intelligence humaine et devient difficile à contrôler.
Voici le rapport d'Accomplish AI sur la faille SharedRoot affectant Claude Cowork :
SharedRoot ; Sortir du bac à sable de Claude Cowork
Un contenu non fiable dans une session Claude Cowork peut s'échapper de la machine virtuelle dans laquelle il est isolé et lire ou écrire des fichiers n'importe où sur votre Mac. Le bug du noyau qui rend cela possible n'est pas le plus intéressant. Ce sont plutôt quatre choix de conception qui le sont, et ceux-ci auraient également empêché l'apparition d'un prochain bug du noyau.
Les chercheurs ont associé un dossier à une nouvelle session Claude Cowork, envoyé un court message, puis observé l’agent s’échapper du bac à sable. Depuis l’intérieur de la machine virtuelle, il a accédé au Mac hôte et a lu et écrit des fichiers partout sur celui-ci, bien au-delà du dossier que nous avions associé, sans aucune demande d’autorisation. Clés SSH, identifiants de cloud, tout ce à quoi le compte de l’utilisateur a accès.
Cela n’est pas censé être possible. Cowork exécute l’agent au sein d’une machine virtuelle Linux en tant qu’utilisateur sans privilèges, et la promesse est que tout ce qu’il fait reste à l’intérieur de cette machine virtuelle et des dossiers que vous lui confiez. Cette limite, c’est le produit. Les données d’entrée non fiables ne constituent pas un cas marginal pour un agent, c’est le cas de figure principal. L'utilisateur veut qu’il lise le dépôt qu'il n’a pas créé et le PDF que quelqu’un vous a envoyé par e-mail. La limite est donc la seule chose qui sépare « le modèle a fait une bêtise » de « le modèle avait mes identifiants cloud ».
La conception de Cowork est ici rigoureuse. Une véritable machine virtuelle, un utilisateur de session sans privilèges, un filtre seccomp, une couche de montage intermédiaire. La plupart de ces éléments tiennent la route. Ce qui suit est un exemple de scénario possible. Il faut observer combien d’éléments distincts ont dû s’aligner pour que cela puisse exister.
Cette vulnérabilité a été signalée à Anthropic et a été classée comme « informative ». Cowork utilise désormais l'exécution dans le cloud par défaut, et cette faille d'échappement locale ne semble pas s'appliquer dans ce contexte.
La chaîne
Comment l'évasion a fonctionné
Les éléments en cause sont assez simples. L’application est une application de bureau macOS classique, s’exécutant sous le compte utilisateur. Le travail proprement dit de l’agent s’effectue ailleurs, dans une machine virtuelle Linux lancée via le framework de virtualisation d’Apple. À l’intérieur de cette machine virtuelle, chaque session dispose de son propre utilisateur jetable sans privilèges, encapsulé dans un filtre seccomp, et les dossiers auxquels l'utilisateur se connecte sont mis à disposition sous forme de montages par un démon root appelé coworkd. Utilisateur sans privilèges, appels système restreints, seuls les dossiers de l'utilisateur sont visibles.
Un détail importe plus que les autres : le système de fichiers de l’hôte est partagé en lecture-écriture avec cette machine virtuelle. L’intégralité du répertoire racine de l’hôte /, monté de manière à ce que seul l’utilisateur « guest-root » à l’intérieur de la machine virtuelle puisse y accéder, se trouve à l’emplacement /mnt/.virtiofs-root. C’est au niveau de ce montage que l’échappement se produit : l’intégralité de l’hôte, accessible en écriture, à une seule barrière de privilèges de la sandbox. Les chercheurs ont nommé la chaîne qui y mène « SharedRoot ».
Il convient maintenant à la chaîne d’exploitation proprement dite.
Début : L’agent s’exécute en tant qu’utilisateur de session sans privilèges. Ce n’est pas un bug qui a mené les chercheurs ici, c’est simplement Cowork qui fait son travail sur le contenu qui lui a été fourni.
Obtention des capacités : L’utilisateur de session appelle la fonction unshare pour créer un nouvel espace de noms utilisateur. Au sein de cet espace de noms, il dispose des droits de root et détient l’ensemble complet des capacités Linux, dont CAP_NET_ADMIN. L’invité autorise les espaces de noms d’utilisateurs sans privilèges ; il n’y a donc absolument aucune faille à exploiter à cette étape. Il s’agit d’une fonctionnalité du noyau qui aurait pu être désactivée, mais qui est restée activée.
Accès au code vulnérable : Fort de la capacité CAP_NET_ADMIN, il configure une action de contrôle du trafic (tc) qui utilise le module du noyau act_pedit. La configuration s’effectue via un socket netlink, ce que le filtre seccomp permissif autorise, et le simple fait de référencer le module suffit pour que le noyau le charge automatiquement. Un module réseau dont le bac à sable n’a jamais eu besoin est désormais chargé et accessible.
Obtenir une primitive d’écriture : Sur ce noyau invité, act_pedit est vulnérable à la faille CVE-2026-46331, « pedit COW », un bug Ubuntu rendu public en juin. Cela permet d’altérer le cache de page d’un fichier que l’on est autorisé à lire uniquement. L’utilisateur de la session choisit donc un binaire d’aide appartenant à root qu’il peut lire mais pas écrire, et altère la copie mise en cache. Les octets sur le disque ne changent jamais, ce qui explique en partie pourquoi l’attaque passe inaperçue.
Les chercheurs ont transformé la primitive en « guest-root ». C'est là que cela cesse d'être un bug du noyau. coworkd s'exécute en tant que root, sans protection renforcée, sur une vue du même système de fichiers, avec les mêmes inodes. Au cours de son fonctionnement normal, il relance cet utilitaire, et c'est la copie corrompue qui s'exécute. Comme le processus effectuant l'exécution est déjà root, NoNewPrivs — le mécanisme qui empêche normalement l'acquisition de privilèges lors d'une exécution — n'a rien sur quoi s'appuyer. L’utilisateur de la session est désormais root au sein de l’invité.
L'étape suivante consiste à quitter la machine virtuelle. L’invité root peut accéder à /mnt/.virtiofs-root, c’est-à-dire l’intégralité du répertoire racine / de l’hôte, partagé en lecture-écriture. À partir de là, il lit et écrit directement sur le système de fichiers du Mac hôte, en tant qu’utilisateur du bureau connecté.
Les chercheurs ont exécuté la chaîne complète de bout en bout sur leur propre machine, et cela a fonctionné.
Changer de perspective
Cela n’aurait pas dû se passer ainsi
Il y a bien une vulnérabilité CVE dans cette chaîne, mais son importance est moindre qu’il n’y paraît à première vue.
act_pedit n’est qu’un bug parmi d’autres dans cette catégorie. Le sous-système net/sched de Linux génère régulièrement ce type précis d’escalade de privilèges : un module chargeable automatiquement, un chemin de configuration accessible à un utilisateur sans privilèges, et un bug mémoire à la fin de la chaîne. Corriger celui-ci permet de le corriger. La chaîne se réactive dès la prochaine faille, sans que rien au-dessus du noyau ne soit affecté.
Et la prochaine ne tarde jamais à arriver. La recherche de vulnérabilités assistée par l’IA s’est industrialisée au cours de l’année dernière. Un modèle OpenAI a découvert une véritable faille « zero-day » exploitable à distance dans le serveur SMB du noyau simplement en lisant le code ; le projet « Big Sleep » de Google et les systèmes qui lui ont succédé ont recensé des dizaines de découvertes dans les principaux projets.Selon une analyse, le nombre d’avis de sécurité concernant l’escalade de privilèges dans le noyau principal a été environ 2,3 fois supérieur à celui de l’année précédente, le début de l’année 2026 s’annonçant comme la nouvelle norme plutôt que comme un pic ponctuel. Et le délai entre la publication d’un correctif et l’apparition d’un exploit public fonctionnel s’est réduit à quelques heures.
Mettre tout cela bout à bout montre que le noyau invité n'est pratiquement jamais à jour : à tout moment, il est probable qu’il soit encore exposé à un bug d’élévation de privilèges, parfois corrigé en amont mais pas encore dans votre image, parfois pas encore corrigé nulle part, avec un exploit fonctionnel disponible en quelques heures. Ce n’est pas un problème de rapidité de correction. L'utilisateur a structurellement un bug de retard, en permanence.
Le confinement n’a jamais vraiment relevé de la responsabilité du noyau. Il dépend de quatre choix situés en amont, et chacun d’entre eux, à lui seul, brise la chaîne qui vient d'être parcourue. Mieux encore, contrairement à la correction du bogue, chacun d’entre eux met hors jeu toute une catégorie, ce qui élimine également la prochaine faille « 1-day » concernant net/sched ou io_uring.
- Ne pas distribuer d’espaces de noms d’utilisateurs non privilégiés. Définir apparmor_restrict_unprivileged_userns=1 (ou kernel.unprivileged_userns_clone=0) et la première étape échoue. L’utilisateur de la session n’accède jamais à un espace de noms où il est root, n’obtient jamais CAP_NET_ADMIN et n’a rien pour configurer tc. La chaîne s’interrompt avant même d’avoir commencé. Ce simple paramètre sysctl a un impact considérable.
- Faire en sorte que le filtre seccomp refuse l’accès. Le filtre du bac à sable est une liste de refus par défaut : il bloque quelques éléments spécifiques et laisse passer le reste, y compris les appels unshare/clone et le socket netlink dont la chaîne a besoin. Il convient d'inverser la stratégie. Bloquer les appels [C]unshare[/], setns et clone3, rejeter les indicateurs de création d’espace de noms lors de l’appel clone, et transformer socket() en une liste d’autorisation par famille d’adresses qui refuse AF_NETLINK. L’une ou l’autre de ces modifications coupe la route à act_pedit.
- Éliminer la voie d’escalade des privilèges. Le module act_pedit est chargé à la demande, car rien n’indique le contraire. Il ne faut pas distribuer de modules dont l’invité n’a pas besoin ; pour ceux qui restent, utiliser install ... /bin/false afin que le chargement automatique échoue. Cela inclut act_pedit et tous les modules net/sched inutilisés. C’est la mesure la plus difficile à généraliser : elle élimine tous les bogues de chargement automatique dans les modules inutilisés, et pas seulement ce CVE. Et ce n’est pas une solution farfelue. Cowork utilise déjà exactement cette méthode, install ... /bin/false, pour un autre module, afin de corriger une faille CVE antérieure. Le modèle existe déjà dans l’image. Il n’a simplement pas été appliqué ici. De plus, il faut supprimer la cible : maintenir tout programme auxiliaire que coworkd pourrait exécuter hors de la vue du système de fichiers de l’utilisateur de la session, afin qu’il ne puisse pas réexécuter un binaire que l’utilisateur de la session pourrait corrompre.
- Et surtout, ne partagez pas l’intégralité de l’hôte avec la machine virtuelle. Le partage en question n’est pas une fenêtre limitée et en lecture seule ; il s’agit de l’intégralité du répertoire racine / de l’hôte, monté en lecture-écriture. Il faut le limiter aux dossiers qui étaient effectivement connectés. Ainsi, même un utilisateur « guest-root » disposant de tous les privilèges n’aura nulle part où aller : il ne pourra accéder qu’à ces dossiers. Compte tenu de tout ce qui a été dit plus haut concernant la fréquence des bogues du noyau, c’est le choix qui a le plus de poids. C’est ce qui détermine si l’accès root dans la VM reste un événement isolé ou s’il entraîne la compromission de l’hôte.
Les chercheurs ont signalé cette chaîne à Anthropic. Ils ont classé le rapport comme « informatif » : le CVE relevait de la période couverte par leur programme, à savoir les failles publiées au cours des 30 derniers jours, et ils ont considéré les mesures de renforcement de la sécurité comme des éléments de défense en profondeur plutôt que comme des vulnérabilités à part entière. C’est une décision raisonnable dans le cadre d’un programme de prime. Mais la portée d’un programme et l'exposition de l'utilisateur sur son propre ordinateur portable sont deux questions distinctes. Du point de vue de l’utilisateur, « nous intégrons les correctifs du noyau dès que l’amont les publie » signifie que la sécurité de la machine dépend d’une course aux correctifs à laquelle il ne participe pas et qu'il ne peut pas gagner.
La conception
C’est pourquoi l'équipe a conçu Accomplish de cette manière
L'équipe a mis en place un moyen permettant aux équipes d’exécuter Claude et d’autres agents sur leurs terminaux, et lors de sa conception, elle n'a cessé de revenir à la leçon mentionnée ci-dessus. L’isolation ne peut pas reposer sur la « propreté » du noyau invité, car celle-ci n’est jamais garantie. Un élément dans net/sched, ou io_uring, ou quelque part où personne ne regarde encore, est toujours à un « N-day » de nous.
L'équipe traite donc l’ensemble de la machine virtuelle invitée comme non fiable, y compris les privilèges root. Les composants qui assurent le confinement s’exécutent sur l’hôte, en dehors de la machine virtuelle ; ainsi, le confinement ne repose pas sur le fait que l’agent reste sans privilèges à l’intérieur de celle-ci. Nous continuons à rendre l’accès aux privilèges root difficile, mais elle ne compte tout simplement pas là-dessus.
Source : Accomplish
Et vous ?
Selon vous, faut-il mieux protéger les agents ou limiter leur utilisation locale ?
Voir aussi :
Répondre avec citation
Partager