DeepSeek Harness permitió que un agente en sandbox desactivara su propio sandbox. Comprueba tu versión, también dentro de los wrappers de escritorio

Usa DeepSeek Harness 0.1.2-alpha.2 o posterior, y no des por hecho que una app de escritorio que incluye el harness ya lo tiene. DeepSeek lanzó la corrección como una versión rutinaria, sin aviso de seguridad, así que nada en tu canal de actualizaciones te dirá que esto importaba. Nuestro veredicto sobre DeepSeek Harness sigue siendo Precaución: ya parcheado, sirve para experimentos en una máquina virtual desechable, no para equipos con credenciales o código de producción.

Qué ocurrió

OX Research encontró el fallo y lo notificó a VulnCheck, en su papel de CNA, el 24 de agosto. VulnCheck publicó CVE-2026-82533 el 8 de septiembre con una puntuación CVSS v4 de 9,4.

• La API. VulnCheck: el harness «concede acceso sin autenticación a su API HTTP local de control de agentes» al «aceptar una cabecera Host de loopback proporcionada por el cliente en lugar de validar el origen real de la conexión TCP».
• El escape. OX Research: el sandbox del sistema operativo confinaba el sistema de archivos pero dejaba la red abierta, de modo que el loopback era accesible desde dentro. Un agente en sandbox ejecutó un único comando contra esa API y elevó su propia sesión a danger-full-access, con las solicitudes de aprobación desactivadas.
• Instalaciones expuestas. VulnCheck afirma que, cuando la interfaz es accesible desde fuera, un atacante remoto puede «crear sesiones, ejecutar comandos arbitrarios y exfiltrar las transcripciones de conversaciones almacenadas sin credenciales».

Versiones

Según las enumera The Hacker News:

VulnCheck y OX Research señalan la 0.1.2-alpha.1 como la corrección, pero esa compilación nunca llegó a npm. Si instalas desde npm, tu mínimo es la 0.1.2-alpha.2.

Por qué importa

La solicitud de aprobación y el sandbox son los dos controles que te permiten dejar un agente de programación funcionando sin supervisión. Este fallo permitía que el agente desactivara ambos por sí mismo, sin pedir permiso.

• Sin aviso. The Hacker News informa de que la versión con la corrección lo incluyó entre los cambios rutinarios, como un cambio que exige «autenticación con token de un solo uso para el acceso en red», sin aviso de seguridad y sin mención del CVE. El proyecto no tiene un archivo de política de seguridad.
• Advertencias anteriores. Dos desarrolladores comunicaron el mismo escape en el foro de discusión de DeepSeek el 13 y el 14 de agosto, con la salida de una prueba de concepto, antes de que existiera el CVE.
• Wrappers. Las compilaciones de escritorio de terceros fijan su propia copia del harness. The Hacker News cita una compilación para Windows que fijó la 0.1.1-rc.2 a finales de agosto y no pasó a la 0.1.3-alpha.1, ya corregida, hasta el 6 de septiembre.
• Alcance. El repositorio tenía más de 216.000 estrellas el 9 de septiembre, cifra que The Hacker News, con razón, califica como un recuento de marcadores y no de instalaciones.

Qué cambia para ti

El parche añade a la interfaz autenticación con token de un solo uso: un token de arranque se intercambia por una cookie firmada en cada llamada. Eso cierra este escape. No convierte el sandbox en una barrera de lectura. The Hacker News informa de que, incluso en la última versión, las escrituras se quedan dentro del espacio de trabajo y de las carpetas temporales mientras que «las lecturas y el acceso a la red no están confinados», y a los agentes se les sigue entregando la dirección de la interfaz.

Así que un harness actualizado sigue siendo un agente que puede leer todo lo que puede leer tu cuenta de usuario y comunicarse con la red. Por eso nuestro veredicto sigue en Precaución en lugar de subir.

Preguntas frecuentes

¿Basta con la 0.1.2-alpha.1? Solo si compilaste desde GitHub. Nunca se publicó en npm; la primera versión corregida en npm es la 0.1.2-alpha.2.

He actualizado mi app de escritorio. ¿Estoy protegido? No necesariamente. Comprueba la versión del harness que incluye la app; los wrappers fijan su propia copia y se actualizaron según su propio calendario.

Mi interfaz solo estaba en localhost. ¿Estuve expuesto? Al escape del sandbox, sí: el atacante en ese escenario es el propio agente, que se ejecuta en tu máquina. La ejecución remota de comandos y el robo de transcripciones requieren que la interfaz sea accesible desde fuera.