Qué alcanzó un solo mensaje

El 23 de julio, la firma de seguridad Accomplish reveló un fallo al que llamó SharedRoot. Su investigador principal, Oren Yomtov, describió la prueba con sobriedad: conectaron una carpeta a una sesión nueva de Claude Cowork, enviaron un mensaje breve y vieron cómo el agente salía de la sandbox.

Claude Cowork ejecuta su agente dentro de una máquina virtual Linux en el Mac, construida sobre el propio marco de virtualización de Apple. Cada sesión recibe un usuario sin privilegios y un filtrado de llamadas al sistema, que es lo que da peso a la palabra sandbox. El problema no era la caja. Era lo que la caja podía ver.

Todo el sistema de archivos del anfitrión estaba montado en esa máquina con acceso de lectura y escritura. Desde dentro, el agente alcanzó claves SSH, credenciales de nube, claves de API, repositorios de código y todo lo demás que la cuenta conectada pudiera tocar. Según el recuento de la firma, unas 500.000 personas habían ejecutado Cowork en local antes de que se resolviera la exposición.

Por qué no llegó un parche

Anthropic recibió el informe y lo cerró como informativo. En el lenguaje de los programas de recompensas por fallos, eso es un reconocimiento sin parche propio, y la empresa lo situó dentro de la ventana de treinta días que su programa reserva para estos casos.

Su respuesta fue arquitectónica, no correctiva. La versión actual de Cowork ejecuta el agente por defecto en la nube de Anthropic, y los investigadores coinciden en que esta vía de fuga local no parece aplicarse allí. El valor por defecto apartó el riesgo de la máquina del cliente, para quien lo acepte.

Queda así una línea clara en el medio. Si sus desarrolladores usan el agente en el modo de nube por defecto, esta fuga no es su problema. Si eligen la ejecución local, por privacidad, por trabajo sin conexión o por costumbre, cargan con toda la exposición, y ninguna actualización la eliminará por ellos.

El límite era un montaje, no un muro

El detalle instructivo es lo corriente que era la debilidad. El sistema de archivos del anfitrión estaba compartido con la máquina virtual de modo que solo el usuario root del huésped debiera verlo. La fuga simplemente se convirtió en root dentro del huésped, mediante un fallo conocido del núcleo de Linux identificado como CVE-2026-46331, y el montaje hizo el resto.

La lección para los defensores no es el error de un único proveedor, sino su forma. Una sandbox que comparte todo el anfitrión es tan fuerte como la suposición de que nada dentro llegará nunca a root. Con un agente que lee contenido no verificado y actúa sobre él, esa es justo la suposición que no debería hacer.

Qué asegurar antes de ejecutarlo en local

Trate cualquier máquina que ejecute un agente local como si el agente pudiera leer la carpeta personal, porque en este caso podía. Mantenga las claves SSH y las credenciales de nube fuera de los portátiles de desarrollo que ejecutan agentes con contenido no verificado, o limite esos agentes para que el sistema de archivos del anfitrión se comparta solo con las carpetas conectadas y en modo de solo lectura.

Donde la plataforma lo permita, los investigadores recomiendan desactivar los espacios de nombres de usuario sin privilegios, endurecer el filtro de llamadas al sistema e impedir la carga bajo demanda de módulos del núcleo no usados - los pasos que habrían bloqueado esta cadena. Son controles de configuración, y por tanto le corresponden a usted, no al proveedor.

El deber de notificación también es suyo. Con NIS2 en la Unión Europea, y con DORA para las entidades financieras, una credencial de desarrollador filtrada que llega a producción es su incidente, y usted lo declara en plazo - en España ante el INCIBE y su CERT. La sandbox se vendió como seguridad; la responsabilidad siempre fue suya.

Leer a continuación: La puerta abierta era el repositorio de paquetes  |  Una IA ejecutó sola todo un ataque de ransomware