Se detectó una vulnerabilidad grave (CVE-2026-82533) en DeepSeek Harness que permitía a los agentes de IA desactivar su propio sandbox con un solo comando. El fallo permitía saltar las restricciones de escritura y acceder a archivos fuera del espacio de trabajo debido a una falta de autenticación en la interfaz web local. DeepSeek ya corrigió el error en la versión 0.1.2-alpha.2 y posteriores, implementando un sistema de tokens de seguridad.

Un fallo en DeepSeek Harness, la herramienta de código abierto de DeepSeek para ejecutar agentes de programación de IA en la máquina de un desarrollador, permitía que un agente en entorno aislado (sandbox) desactivara su propio sandbox con un solo comando.

La herramienta ejecuta los comandos de un agente dentro de un sandbox del sistema operativo, para que un agente que trabaje con archivos no fiables no pueda escribir fuera de su espacio de trabajo. El agente podía eliminar ese límite llamando a la propia interfaz web de la herramienta en la misma máquina, y sus comandos se ejecutarían entonces fuera del sandbox sin necesidad de un aviso de aprobación.

Funcionaba en una instalación predeterminada hasta que DeepSeek corrigió la herramienta el 27 de agosto, y requería un texto proporcionado por el atacante que el agente leyera para incitarlo a realizar la llamada.

El fallo se identifica como CVE-2026-82533. VulnCheck, que asignó el identificador, publicó el registro aquí el 8 de septiembre y calificó el fallo con un 9,4 sobre 10.

OX Research aquí, la firma de seguridad que informó del fallo, afirmó que un solo comando de shell era suficiente. El comando invocaba la interfaz local de la herramienta y configuraba la sesión del agente en un modo llamado danger-full-access, que desactiva el sandbox y detiene los avisos de aprobación.

Los comandos ordinarios no necesitaban aprobación para empezar. La aprobación se aplicaba solo cuando un comando solicitaba un acceso más amplio del que la sesión ya tenía, y esta llamada no lo solicitaba. En su lugar, cambiaba la configuración de la sesión.

OX afirmó que comprobó que el sandbox había estado funcionando antes del escape. Ejecutó dos sesiones con la misma configuración predeterminada y dio a ambas el mismo comando. La sesión que había realizado la llamada escribió en una carpeta fuera de su espacio de trabajo, y la otra fue bloqueada.

El sandbox solo cubre los archivos. La referencia de la línea de comandos para la versión afectada aquí dice que, bajo la configuración predeterminada, las escrituras permanecen dentro del espacio de trabajo y las carpetas temporales, mientras que "las lecturas y el acceso a la red no están confinados".



Esto dejaba la propia interfaz de la herramienta accesible desde dentro del sandbox. La herramienta también proporciona al shell del agente la dirección de esa interfaz y el identificador de la sesión actual, para que el agente no tenga que buscarlos.

La interfaz no tenía autenticación. En la versión afectada, la comprobación que determinaba si una solicitud podía llegar a ella aquí leía la cabecera Host de la solicitud y nunca miraba de dónde procedía la conexión. Un comentario en ese archivo dice que la comprobación "no es una capa de autenticación".

Esa comprobación es lo que describe el registro CVE. Debido a que confiaba en una cabecera que el cliente proporciona, una máquina externa podría afirmar que es local y controlar al agente. La línea de comandos de la herramienta se negaba a escuchar en todas las interfaces de red, por lo que para acceder a ella desde fuera era necesario que tú hubieras reenviado o proxificado el puerto a través de un túnel, un reenvío SSH o un editor.



La misma interfaz servía una solicitud para descargar el registro completo de una sesión. El aviso de VulnCheck establece que quien acceda a la interfaz podría recuperar todas las conversaciones almacenadas sin una clave.

Versiones afectadas y qué instalar

Las versiones 0.1.1-rc.2 y anteriores están afectadas. El registro nombra a la 0.1.2-alpha.1 como la versión corregida, pero esa versión nunca se publicó en el registro npm, que es donde las propias instrucciones del proyecto envían a los usuarios.

Estado de la versión:
0.1.1-rc.2 y anteriores: Afectadas
0.1.1-rc.2 publicada el 21 de agosto
0.1.2-alpha.1: Corregida, solo en GitHub el 27 de agosto, no en npm
0.1.2-alpha.2: Primera versión corregida en npm el 30 de agosto
0.1.2-rc.1: Versión actual de npm, incluye la corrección el 3 de septiembre

The Hacker News comprobó el registro npm aquí el 9 de septiembre y descubrió que la primera versión publicada con el cambio de autenticación es la 0.1.2-alpha.2, tres días después de que la corrección se subiera a GitHub.

1. Instala la versión 0.1.2-alpha.2 o posterior. La versión actual del registro es la 0.1.2-rc.1.
2. Si instalaste a través de una aplicación de escritorio de terceros, comprueba qué versión del harness incluye.
3. Si no puedes actualizar, detén la interfaz web cuando no la estés usando y elimina cualquier túnel, proxy o reenvío de puerto que llegue a ella.

Ninguna fuente revisada para este artículo ofrece una forma de detener el escape desde dentro del sandbox en una instalación local predeterminada mientras la herramienta está en funcionamiento. El informe del 13 de agosto dice que limitar la dirección en la que escucha la herramienta no ayuda, porque el agente ya está en la misma máquina.

La corrección otorga a la interfaz una comprobación de identidad. Ahora la herramienta imprime un token de un solo uso en su dirección de inicio; el navegador intercambia ese token por una cookie firmada, y cada llamada a la interfaz requiere la cookie aquí.

Lo que la corrección no cambia es el sandbox. En la 0.1.2-rc.1, la misma referencia sigue diciendo que las lecturas y el acceso a la red no están confinados, y el shell del agente sigue recibiendo la dirección de la interfaz. Ninguna fuente aborda si un agente que se ejecuta dentro de su espacio de trabajo puede seguir obteniendo una sesión válida bajo el nuevo esquema.

Las compilaciones de escritorio de terceros incluyen su propia copia del harness, y qué copia incluyen es elección del mantenedor del wrapper. Una compilación de Windows fijó la 0.1.1-rc.2 a finales de agosto y pasó a la 0.1.3-alpha.1, que incluye la corrección, el 6 de septiembre aquí. Cualquiera que haya instalado el harness a través de un wrapper debería comprobar qué versión incluye.

Un harness de agente de programación merece ser atacado porque posee un shell. DeepSeek Harness ejecuta los comandos de un agente bajo la cuenta que lo inició.

El propio aviso de seguridad del proyecto aquí establece que el software no ha sido sometido a una auditoría de seguridad y que el sandboxing y los avisos de aprobación "no garantizan el aislamiento ni evitan daños". Indica a los usuarios que no confíen en la herramienta como su único control de seguridad para trabajos no fiables.

El repositorio tenía más de 216.000 estrellas el 9 de septiembre, un recuento de cuentas que lo marcaron como favorito más que de instalaciones.

Los investigadores han encontrado repetidamente agentes de programación escapando de sus sandboxes este año, incluyendo un conjunto de fallos en los que la propia configuración de un repositorio provocaba que los agentes ejecutaran código del atacante fuera de sus sandboxes.

Informes de la comunidad describieron el mismo escape en agosto

Dos desarrolladores describieron el mismo escape en el propio tablero de discusión de DeepSeek antes de que existiera el CVE. El 13 de agosto, uno publicó un informe aquí mostrando un proceso aún retenido por el sandbox llegando a la interfaz local y luego cambiando la sesión a danger-full-access, con salida de prueba.

El 14 de agosto, otro publicó un informe aquí sobre la misma interfaz, enumerando las solicitudes que aceptaba sin ninguna credencial.

Ese segundo informe también señaló que el proyecto no tenía un archivo de política de seguridad ni una forma privada de informar de un fallo. El proyecto sigue sin tener un archivo de política de seguridad.

OX Research informó del fallo a VulnCheck el 24 de agosto, según su propio cronograma, y VulnCheck acredita a Nir Zadok y Moshe Siman Tov Bustan. La publicación de OX no menciona los informes anteriores.

The Hacker News revisó la lista de avisos del repositorio el 9 de septiembre y no encontró ningún aviso de seguridad publicado. La versión que incluía la corrección aquí la enumera entre cambios rutinarios, como la eliminación de un transporte antiguo y el requerimiento de "autenticación de token de un solo uso para el acceso a la red", sin aviso de seguridad y sin mención al CVE.

Fuente:
THN