SharedRoot: la vulnerabilidad en Claude Cowork para macOS que permitía a una VM leer y escribir en todo el Mac

Investigadores de seguridad han revelado una vulnerabilidad crítica en la versión de escritorio de Anthropic Claude Cowork para macOS que permitía a un agente escapar de su máquina virtual Linux y leer o escribir archivos en todo el sistema del Mac donde se ejecutaba la sesión local. El hallazgo, bautizado como SharedRoot por quienes lo descubrieron, expone el riesgo real de correr agentes basados en VMs locales con montajes amplios del sistema de ficheros y capacidades de red sin las restricciones adecuadas.

Según la empresa que reportó el fallo, Accomplish AI, la técnica funcionaba porque la VM invitada montaba el sistema de ficheros del anfitrión con acceso de lectura-escritura en un punto accesible para el usuario root dentro del invitado. Una cadena de explotación aprovechaba la capacidad de crear espacios de nombres no privilegiados y la carga del subsistema act_pedit del kernel Linux para desencadenar un desbordamiento conocido en la ruta pedit COW (asociado a la clasificación de tráfico), con lo que el proceso en la VM obtenía privilegios equivalentes a root en la invitada y, a través del montaje compartido, acceso a todo el Mac del usuario.

El peligro práctico es sencillo y grave: un agente que logra esta escalada puede leer claves SSH, credenciales almacenadas, ficheros con tokens de nube y otros secretos del usuario que ejecuta la aplicación en el escritorio. Los descubridores estimaron que hasta medio millón de instancias locales podrían haber estado expuestas antes de que Anthropic cambiara el comportamiento por defecto hacia la ejecución en la nube.

Anthropic respondió cerrando el informe como informativo y cambiando la ejecución por defecto a la nube, lo que reduce el vector de ataque para la mayoría de usuarios. Sin embargo, quienes elijan explícitamente ejecutar sesiones de Cowork en local siguen en riesgo si no aplican mitigaciones adicionales o si el kernel/imagen de VM no está parcheado. Este episodio subraya una lección mayor: la ergonomía de ejecutar modelos localmente puede chocar con limitaciones estructurales de seguridad cuando el diseño confía en montajes compartidos y en módulos del kernel que pueden explotarse desde un contexto no privilegiado.

Desde el punto de vista técnico, la vulnerabilidad es representativa de una clase recurrente en subsistemas de red y programación del kernel: un módulo que se autoloadea, una ruta de configuración accesible por usuarios no privilegios y un fallo de memoria que convierte esa ruta en un escalado efectivo de privilegios. Como resumen, parchear un CVE concreto resuelve esa instancia, pero deja intacto el patrón que permitirá que surja la siguiente falla similar si no se actúan medidas estructurales de contención.

Para usuarios que utilicen Claude Cowork en macOS recomiendo, en este orden: asegurar que la aplicación esté actualizada y preferir la ejecución en la nube si no es imprescindible trabajar en local; revisar las preferencias y evitar compartir la raíz del sistema (/) con la VM; montar únicamente las carpetas concretas que necesite la sesión y, cuando sea posible, hacerlo en modo lectura; y rotar claves y credenciales si se sospecha que una sesión local pudo haberse visto comprometida. También conviene auditar archivos recientes y registros del sistema por actividad inusual y, ante la duda, revocar tokens o claves SSH y generarlos de nuevo.

Para administradores y desarrolladores de soluciones que embeben agentes en VMs, las recomendaciones técnicas prácticas son claras: no montar todo el sistema del anfitrión con permisos de escritura en la VM; limitar las capacidades que se conceden al proceso de usuario dentro del contenedor o VM (evitar CAP_NET_ADMIN si no es estrictamente necesario); desactivar o restringir espacios de nombres no privilegiados cuando el entorno lo permita; endurecer filtros seccomp para reducir llamadas permitidas; impedir la autoload de módulos del kernel desde contextos expuestos; y ejecutar procesos de gestión como coworkd en un nombre de montaje y usuario propio con políticas de solo lectura y ProtectSystem=strict para que no puedan ser re-ejecutados por usuarios de sesión.

Además de estas medidas puntuales, conviene adoptar un enfoque de defensa en profundidad: contener el impacto de una posible escalada de la VM haciendo que, incluso con guest-root, no haya vectores fáciles para atacar el anfitrión. Montajes read-only, menor exposición de dispositivos virtuales y una política clara sobre cuándo es aceptable ejecutar modelos localmente frente a ejecutar en la nube ayudan a reducir la ventana de exposición.

Este incidente recuerda la tensión entre funcionalidad offline y seguridad: la capacidad de ejecutar agentes complejos en un equipo local tiene ventajas de latencia y privacidad, pero exige controles más estrictos en el aislamiento de las VMs y el kernel. Mientras tanto, los proveedores deben priorizar no solo parches reactivos, sino cambios de diseño que eliminen la dependencia de caminos de explotación repetibles.

Si buscas documentación técnica de referencia sobre el marco de virtualización de Apple y sobre cómo Linux gestiona espacios de nombres y capacidades, puedes consultar la documentación oficial de Apple en Apple Virtualization Framework y la guía del kernel en kernel.org sobre user namespaces. Mantenerse informado y aplicar medidas de mitigación es la forma más práctica de reducir el riesgo mientras la comunidad corrige la superficie de ataque.