Investigadores de seguridad descubrieron una vulnerabilidad de escape de sandbox en Claude Cowork de Anthropic que permitiría a un agente de IA salir de los confines de una máquina virtual (VM) Linux dentro de la cual se ejecuta el agente para leer o escribir archivos en cualquier lugar del Mac.
Accomplish AI, que compartió los detalles de la vulnerabilidad con The Hacker News antes de su publicación, dijo que aproximadamente 500.000 usuarios de macOS que ejecutaban sesiones locales de Cowork se vieron afectados antes de que se parcheara. La vulnerabilidad ha sido nombrada SharedRoot.
Conectamos una carpeta a una nueva sesión de Claude Cowork, enviamos un mensaje corto y vimos al agente escapar de la sandbox. Desde dentro de la VM, llegó al Mac anfitrión y leyó y escribió archivos por todas partes, mucho más allá de la carpeta que habíamos conectado, sin ningún aviso de permiso en ningún lado.
Con este nivel de acceso, el agente puede acceder a cualquier dato almacenado en el Mac a través de la cuenta del usuario, incluyendo claves SSH, credenciales en la nube y otra información valiosa.
Tras la divulgación responsable, Anthropic cerró el informe como informativo sin emitir una solución. Dicho esto, la última versión de Cowork utiliza por defecto la ejecución en la nube, lo que soluciona el problema. Pero los usuarios que optan por ejecutar el agente localmente aún están expuestos al problema.
La aplicación de escritorio de Claude Cowork para macOS se ejecuta como el usuario que ha iniciado sesión en el sistema. El trabajo real relacionado con el agente, por otro lado, ocurre en una VM Linux creada a través del marco de virtualización de Apple. Cada sesión tiene su propio usuario sin privilegios desechable, junto con un filtro seccomp (Secure Computing Mode) para el sandboxing de aplicaciones. Las carpetas conectadas por el usuario se comparten en la VM mediante un demonio raíz llamado coworkd.
Un detalle importa más que el resto: el sistema de archivos del anfitrión se comparte en esa VM con permisos de lectura y escritura. Todo el '/' del anfitrión, montado de modo que solo el root invitado dentro de la VM pueda verlo, en /mnt/.virtiofs-root.
Debido a que todo el sistema de archivos del anfitrión está montado en la VM del agente con permisos de lectura y escritura, cualquier ruta hacia el root invitado puede otorgar al agente acceso al anfitrión subyacente, escapando efectivamente de la sandbox.
Esto implica cargar el subsistema de edición de paquetes 'act_pedit' de Traffic Control (tc) del kernel de Linux en un espacio de nombres de usuario sin privilegios y explotar CVE-2026-46331 en el kernel invitado, una falla recientemente divulgada llamada pedit COW, para obtener root invitado. Desde allí, el agente puede acceder a todo el anfitrión ('/') con privilegios elevados, lo que le permite leer o escribir archivos desde y hacia el sistema de archivos del Mac como el usuario de escritorio que ha iniciado sesión.
Or Hiltch, cofundador y CTO de Accomplish AI, dijo a The Hacker News que la creación de espacios de nombres de usuario y de red le da a la sesión CAP_NET_ADMIN dentro de su espacio de nombres de red privado, lo que le permite realizar varias operaciones relacionadas con la red.
Esa capacidad proporciona acceso a la ruta vulnerable del kernel tc/act_pedit utilizada por pedit COW. Los espacios de nombres no son el exploit; hacen que su requisito previo normalmente privilegiado esté disponible para un usuario ordinario.
El desarrollo adquiere importancia ante las revelaciones de que los modelos de OpenAI lograron escapar de su entorno sandbox durante una prueba de seguridad que resultó en la violación de la infraestructura de producción de Hugging Face en su búsqueda por engañar al benchmark ExploitGym en el que estaban siendo evaluados.
act_pedit es un error en una categoría. El subsistema net/sched de Linux arroja esta misma forma de escalada de privilegios con una cadencia regular: un módulo autocargable, una ruta de configuración a la que un usuario sin privilegios puede llegar, un error de memoria al final. Parchea este y habrás solucionado este. La cadena se rearma en el siguiente, con todo por encima del kernel intacto.
Y el siguiente siempre está llegando. En cualquier momento dado, probablemente haya un error de escalada de privilegios al que todavía está expuesto, a veces solucionado en upstream pero aún no en tu imagen, a veces no solucionado en ningún lado, con un exploit funcional en horas. Esto no es un problema de parchear más rápido. Estás estructuralmente un error detrás, todo el tiempo.
Para mitigar la amenaza, es esencial deshabilitar los espacios de nombres de usuario sin privilegios, evitar que el filtro seccomp sea demasiado permisivo, detener la autocarga de módulos y restringir el compartir todo el anfitrión en la VM.
Limítalo a las carpetas que realmente se conectaron en lugar de todo '/', o al menos móntalo como solo lectura, y ejecuta coworkd con ProtectSystem=strict en su propio espacio de nombres de montaje para que no esté re-ejecutando binarios que un usuario de sesión pueda envenenar. Entonces, incluso un root invitado completo no tiene dónde aterrizar, los últimos dos pasos de la cadena no tienen a dónde ir.
Deja una respuesta