Escape del sandbox de Cowork: un RPC firmado que confiaba en los privilegios del cliente
Unos investigadores encadenaron un DLL sideloading y un RPC por named pipe demasiado permisivo para llegar a root dentro del sandbox Linux de Claude Cowork. Anthropic considera la ejecución local un requisito, no un fallo.
¿Qué es esto?
El 2 y 3 de julio de 2026, varios medios de seguridad difundieron un análisis de Nick McClendon (Armadin) que describe un escape completo del sandbox Linux integrado en Claude Cowork, el producto de escritorio de Anthropic para perfiles no técnicos. La cadena permite que un atacante que ya dispone de ejecución de código en el host obtenga una shell de root dentro del sandbox del agente, desactive el control de salida de red y escape hacia los espacios de nombres de la VM anfitriona. Según esas mismas fuentes, el hallazgo se comunicó a Anthropic el 20 de marzo de 2026 y se validó sobre la versión 1.9255.2.0 de Claude Desktop para Windows. Esto es un análisis de diseño, no un procedimiento accionable.
Lo relevante no es que un sandbox se rompiera —los sandbox se rompen— sino cómo. El canal de control que gobierna el sandbox autenticaba quién llamaba mientras confiaba en lo que pedía el llamante. Esa confusión entre identidad y autorización es la lección reutilizable para cualquiera que construya un runtime de agente de IA.
Cómo funciona
En Windows, Cowork ejecuta Claude Code dentro de una VM Ubuntu aislada por Hyper-V, aprovisionada mediante el Host Compute Service. El aislamiento es por capas: un servicio Local System (CoworkVMService) expone un servidor JSON-RPC sobre un named pipe y solo acepta a los llamantes cuyo binario porta una firma Authenticode válida de «Anthropic, PBC». Dentro de la VM, el trabajo se ejecuta bajo un espacio de nombres bubblewrap, con un usuario sin privilegios propio de la sesión, tras un filtro seccomp y un proxy de salida restringido por dominio.
Los investigadores intentaron primero falsificar la firma, sin éxito: WinVerifyTrust aguantó. En lugar de romper el control de identidad, lo satisficieron. Como el binario firmado claude.exe resolvía una biblioteca del sistema desde su propio directorio antes que desde la ruta del sistema, una biblioteca gemela colocada junto a él ejecutó código del atacante dentro del proceso firmado y de confianza: un DLL search-order hijack clásico (MITRE ATT&CK T1574.002). El llamante heredaba entonces la confianza de firma de Anthropic y podía dialogar legítimamente con el pipe.
La escalada vino del propio contrato RPC. Los registros del servicio en disco revelaban el esquema de métodos, incluida una llamada spawn con parámetros suministrados por el cliente. Dos de ellos eran aceptados tal cual por el demonio invitado. Un indicador de reanudación de sesión, pensado para reconectarse a una sesión existente, evitaba la ruta que crea un usuario sin privilegios; así, una petición que nombraba a un usuario existente arbitrario (incluido el superusuario) se ejecutaba como ese usuario, con todas las capacidades y un perfil no confinado. Un parámetro de dominios con comodín convertía el proxy de salida restrictivo en uno abierto. Con un proceso root en el espacio de nombres, un simple nsenter contra el PID 1 permitía después salir a los espacios de nombres mount, PID y red de la VM anfitriona, exponiendo archivos como /etc/shadow. Aquí no se reproduce ningún payload; lo que importa es el mecanismo.
Por qué importa
Cada capa de protección funcionó como estaba diseñada, y la caja se abrió igualmente, porque un servidor privilegiado delegó decisiones de seguridad —qué usuario ejecutar, qué dominios alcanzar— en valores controlados por el cliente. Sellar un canal de control con firma prueba la identidad del llamante; no dice nada sobre si una petición concreta debería autorizarse. Es el mismo problema de frontera de confianza que hay tras las fronteras de privilegio del arnés de agente y las fugas por entorno en agentes de código, y es exactamente por lo que el enfoque zero-trust para agentes trata el sandbox como un control más, y no como el control.
La posición de Anthropic, según las fuentes, es que no se trata de una vulnerabilidad de seguridad porque presupone ejecución de código local en el host, fuera de su modelo de amenazas. Es una postura defendible para software clásico, pero merece escrutinio para las herramientas de agentes de IA en particular, porque esas herramientas existen para ejecutar código no confiable y seguir instrucciones no confiables. «Requiere ejecución local» es una frontera más débil cuando ejecutar contenido influido por el atacante es la función central del producto.
Defensas
Para quienes construyen, la regla duradera es que la autenticación no es la autorización: a un llamante firmado o en lista blanca hay que verificarle igualmente cada método y cada parámetro en el servidor, y las decisiones de privilegio o de salida jamás deben tomarse de campos suministrados por el cliente. Las rutas de reanudación/reconexión deben rederivar la identidad del estado del servidor, no de un nombre aportado por el llamante. Endurezca también la base del control de identidad: una puerta por firma vale solo lo que valga la integridad de código del proceso firmado, así que imponga un orden de búsqueda de DLL seguro y la integridad de las aplicaciones empaquetadas para que un binario de confianza no pueda cargar una biblioteca no confiable.
Para quienes operan, trate cualquier entorno que ejecute código generado por IA como no confiable, y apile controles más allá del sandbox: restrinja qué aplicaciones firmadas pueden lanzarse (por ejemplo con reglas de aplicaciones empaquetadas de AppLocker), vigile cargas de bibliotecas anómalas como una DLL del sistema cargada fuera de System32 (Sysmon Event ID 7), mantenga los runtimes de agentes lejos de las redes de producción y de los almacenes de secretos, y alerte sobre cambios de privilegio o salidas de red inesperadas desde los sandbox de agentes. Asuma que se encontrarán escapes y dimensione el radio de impacto en consecuencia.
Estado
| Elemento | Detalle |
|---|---|
| Divulgación | Nick McClendon (Armadin); comunicado a Anthropic el 20 de marzo de 2026; publicaciones públicas el 2–3 de julio de 2026 |
| Naturaleza | Escalada de privilegios y escape del sandbox mediante DLL search-order hijack + RPC de control que confía en privilegios/dominios suministrados por el cliente |
| Validado en | Claude Desktop para Windows build 1.9255.2.0 |
| Requisito previo | Ejecución de código local en el host |
| Postura del fabricante | Clasificado por Anthropic como no vulnerabilidad de seguridad (ejecución local considerada requisito); sin CVE asignado al momento de escribir |
| Clase | Autenticación ≠ autorización; control de acceso defectuoso en el plano de control de un agente |
Los detalles reflejan la cobertura de terceros de la investigación de Armadin, probada sobre una versión concreta de Windows. Las posturas del fabricante y los internos del producto cambian con el tiempo: verifique sobre la versión actual de un despliegue antes de sacar conclusiones.