Docker Sandboxes: sbx cp dejaba escapar al agente

Docker Sandboxes tenía un hueco en sbx cp, la orden que mueve archivos entre la caja del agente y la computadora: un enlace simbólico plantado en la carpeta aprobada dejaba leer y sobrescribir archivos de fuera. El fallo, registrado como CVE-2026-103916, tiene nota 8,2 sobre 10 y ya tiene arreglo: Docker lo cerró el 3 de noviembre en la versión 0.51.0.

La promesa del producto es justo la contraria. Docker Sandboxes corre agentes de programación como Claude Code, Codex y Gemini CLI dentro de una máquina virtual ligera propia, con su núcleo, su sistema de archivos y su red, para que el agente instale y ejecute sin tocar el resto del equipo. El programador aprueba carpetas, y esa lista es la única parte de su computadora que la caja debe ver.

Peyton Kennedy, investigador de Endor Labs, publicó el detalle completo del fallo y su reproducción con un archivo centinela. Ni montando como raíz todo el disco compartido dentro de la máquina virtual logró alcanzar ese archivo protegido: la pared principal aguantó cada prueba. La salida estaba en el canal que casi nadie mira porque forma parte del trabajo diario.

Un atajo dentro de la carpeta aprobada

sbx cp no usa el disco compartido con su lista de carpetas aprobadas. Mueve los datos por un canal separado y ejecuta la mitad de la operación en la propia computadora, con los permisos completos de la persona que lo lanzó. Esa lista nunca se consulta en la copia, y la orden resuelve los enlaces simbólicos de la ruta recibida sin comprobar adónde llevan en la máquina real.

El agente trabaja con permiso de escritura en su carpeta, así que plantar el atajo le cuesta una sola acción: un enlace simbólico donde espera que la persona copie algo. Dentro de la máquina virtual ese enlace cuelga en el vacío, porque la ruta de destino no existe en su vista. Solo cobra vida cuando la orden lo resuelve en la computadora, en una copia que la persona ejecuta.

La orden trae un único control para enlaces, la opción -L, y cubre una sola de las cuatro posiciones donde un enlace puede sentarse en una ruta. Las otras tres se siguen por defecto, incluida la carpeta padre del archivo que se copia hacia adentro. Kennedy lo resume con precisión incómoda: la prueba de -L sobre el nombre final pasa, y no ejercita ninguna de las otras tres posiciones.

Leer hacia afuera sale barato. La caja elige la carpeta y la persona escribe el nombre del archivo, un obstáculo menor cuando los blancos se llaman como se llaman: las credenciales de Amazon Web Services de la carpeta .aws, la llave privada id_ed25519 de SSH o un repositorio vecino. Tras la copia, el archivo queda dentro de la caja, listo para salir por la red del agente.

Escribir fuera vale más que leer fuera

La escritura asusta más. Una copia hacia afuera con el atajo en el destino deja contenido elegido por la caja en cualquier carpeta existente donde la persona pueda escribir: su carpeta personal entera, en la práctica. Endor Labs nombra los blancos que convierten ese gesto en ejecución de código al siguiente uso: el .zshrc, las llaves autorizadas de SSH o un gancho de Git. El investigador lo presenta como razonamiento, no como resultado demostrado.

Nada avisa. Una copia correcta no imprime nada en pantalla, ni siquiera con el modo de depuración, y ninguna ruta resuelta se muestra; la orden de montaje sí imprime la ruta real a la que apuntó. El camino para manipular al agente también está descrito: instrucciones ocultas en contenido que el agente procesa, la inyección de instrucciones, pueden empujarlo a plantar el enlace y proponer la copia como un paso rutinario.

El riesgo ya tenía antecedentes. Otro escape de sbx cp, el CVE-2026-17106, se cerró en la 0.38.0 y su contención aguantó; el fallo nuevo vive en la raíz de destino y en la ruta de entrada, que aquella corrección no revisaba. Para quien deja agentes sobre su código, el patrón se repite en otro frente: las claves de Claude Code públicas en GitHub mostraron el 9 de noviembre cuánto secreto circula en estas sesiones.

Docker movió el arreglo dos veces. La primera fecha fue el 13 de octubre, con la versión 0.48.0, pero el equipo comprobó que la corrección quedaba incompleta y la definitiva salió el 3 de noviembre con la 0.51.0; ya existe la 0.53.0, del 11 de noviembre. Las notas oficiales de Docker confirman el cambio: sbx cp bloquea los enlaces simbólicos que escapan de las carpetas montadas hacia otras rutas.

Mientras la actualización llega, el consejo del investigador es tratar cada copia como si la hubiera escrito un desconocido. Antes de copiar, conviene resolver la ruta con realpath y comprobar que cae dentro de la carpeta aprobada, revisando cada componente, del primero al último. Mejor todavía: copiar hacia carpetas que la caja nunca tuvo montadas, y mirar con lupa doble las copias que el propio agente propone.

Queda un dato que ordena todo el caso. El ejemplo que la ayuda de la orden enseña, copiar un registro de salida a la carpeta del proyecto, era la única acción que el ataque necesitaba de la persona. La máquina virtual, su núcleo separado y su lista de carpetas funcionaron; el fallo vivía en el trasiego de archivos que el producto daba por resuelto.

Fuente: Endor Labs