DeepSeek Harness CVE-2026-82533: un agente en sandbox desactiva su propio sandbox con un solo comando

VulnCheck publicó CVE-2026-82533 el 8 de septiembre de 2026: una omisión crítica de autenticación que permitía a un agente de programación con IA desactivar su propio sandbox con un solo comando de shell. El software es DeepSeek Harness, el entorno de ejecución local de código abierto de DeepSeek para agentes de programación, que, según Cloud Security Alliance, alcanzó aproximadamente 215.000 estrellas de GitHub en pocas semanas; todas las versiones anteriores a 0.1.2-alpha.1 están afectadas. Determinaba si un llamador era local a partir del propio encabezado Host del llamador, por lo que una solicitud podía declarar que provenía de loopback. Como su sandbox restringía las escrituras de archivos pero no las conexiones de red de loopback, un agente confinado podía llamar a la API de control no autenticada del harness en el puerto 3080 y cambiar su sesión a danger-full-access con las aprobaciones desactivadas. VulnCheck le asigna 9,4, crítica; no se afirma que haya habido explotación en el mundo real. El registro es una entrada de un conjunto de datos público de incidentes de IA, y el Orca AI Incident Archive contiene el conjunto completo de registros, con fechas, calificaciones de gravedad y fuentes para cada entrada.

La comprobación que le preguntó a una solicitud qué era

El componente vulnerable es la API local de control de agentes del harness, el pequeño servicio HTTP que la interfaz web y la línea de comandos usan para controlar una sesión en ejecución. Según la nota de investigación de Cloud Security Alliance del 10 de septiembre de 2026, que se basa en el análisis de OX Security, la empresa que encontró la falla, ese servicio escuchaba en 127.0.0.1, puerto 3080, de forma predeterminada, y tomaba su decisión de confianza en una función que la nota llama isTrustedApiRequest. La función leía el encabezado HTTP Host y concedía acceso cuando el valor coincidía con un nombre de loopback como localhost o 127.0.0.1. El encabezado Host son metadatos que escribe el cliente; no dice nada sobre dónde se originó la conexión TCP. The Hacker News, citando la fuente afectada el 9 de septiembre de 2026, informa que la comprobación nunca miró el origen de la conexión y que un comentario en el mismo archivo dice que la comprobación «no es una capa de autenticación».

Eso es todo lo que abarca CWE-807, la confianza en entradas no confiables en una decisión de seguridad, y es lo que describe el registro publicado por VulnCheck: una cabecera Host de loopback proporcionada por el cliente que se acepta en lugar de validar el origen real de la conexión TCP.

Lo que convirtió una comprobación defectuosa en una vía de escape fue que el arnés le entregara al agente sus propias claves. The Hacker News informa que el arnés le pasa al shell del agente la dirección de la interfaz de control y el identificador de la sesión actual, de modo que un comando no tiene que descubrir ninguno de los dos. El sandbox, por su parte, cubría un canal y no el otro: la referencia de línea de comandos de la versión afectada indica que, con la configuración predeterminada, las escrituras se mantienen dentro del espacio de trabajo y las carpetas temporales, mientras que las lecturas y el acceso a la red no están confinados.

¿Por qué las solicitudes de aprobación no lo detuvieron?

El harness sí tenía avisos de aprobación, y no se eludieron tanto como que no resultaban aplicables. The Hacker News informa que, en la versión afectada, solo se solicitaba aprobación cuando un comando buscaba un acceso más amplio que el que ya tenía la sesión. La llamada de escalada no pretendía nada de eso; cambiaba la configuración de la sesión. Un agente que la ejecutó pasó a un modo que OX Security denomina danger-full-access, con los avisos de aprobación configurados en nunca, y siguió ejecutándose como el usuario que había lanzado el harness, completamente fuera del sandbox.

La evidencia de OX Security sobre el límite fue un par controlado. The Hacker News informa que la empresa ejecutó dos sesiones con ajustes predeterminados idénticos y les dio a ambas el mismo comando: la sesión que realizó la llamada escribió en una carpeta fuera de su espacio de trabajo, y la otra fue bloqueada.

El segundo camino, y la condición previa que necesitaba

La misma comprobación ausente exponía el arnés a clientes que nunca estuvieron dentro de una sandbox, pero solo bajo una condición que la configuración predeterminada no generaba. La línea de comandos se negaba a enlazar la API a todas las interfaces de red, por lo que el puerto solo era accesible desde otros lugares si un usuario ya lo había reenviado —mediante un túnel, un proxy inverso, un reenvío SSH o la propia función de reenvío de puertos de un editor—, según The Hacker News; la nota de Cloud Security Alliance enumera el mismo conjunto. Cuando se cumplía esa condición previa, según el aviso de VulnCheck, un cliente sin credenciales podía crear sesiones, ejecutar comandos arbitrarios y exfiltrar transcripciones de conversaciones almacenadas. The Hacker News añade que la misma interfaz atendía una solicitud que descarga el registro completo de una sesión.

La ruta en sandbox necesita una precondición diferente: texto que el agente leerá y sobre el que actuará. La nota de Cloud Security Alliance describe un agente confinado que maneja un prompt proporcionado por el atacante e incrustado en un comentario de código, un archivo README o el texto de una incidencia. Ninguna de las dos rutas requiere una clave robada, y la nota observa que la ruta remota no necesita ninguna interacción con el modelo una vez que el puerto está expuesto.

Por lo tanto, la población expuesta es cualquiera que haya ejecutado el harness en la versión 0.1.1-rc.2 o anterior con la configuración predeterminada, un conjunto que el recuento de estrellas solo insinúa. The Hacker News contabilizó más de 216.000 estrellas el 9 de septiembre de 2026 y advirtió que una estrella es un marcador y no una instalación.

Qué está establecido y qué no

Establecido, a partir del propio registro CVE: VulnCheck es la autoridad de numeración, reservó el identificador el 29 de agosto de 2026 y publicó el registro el 8 de septiembre a las 16:59 UTC; la debilidad es CWE-807; el rango afectado es todas las versiones anteriores a 0.1.2-alpha.1; y el crédito corresponde a Nir Zadok y Moshe Siman Tov Bustan. Las dos puntuaciones que incluye el registro, 9,4 según CVSS 4.0 y 9,6 según CVSS 3.1, provienen de VulnCheck y no de un segundo evaluador independiente —NVD enumera ambas métricas con VulnCheck como su fuente—, por lo que son una sola evaluación expresada en dos marcos, no dos evaluaciones que coinciden.

Queda establecido, a partir del repositorio: el commit de corrección 3e24087, titulado «fix(web): authenticate the browser Host API», está fechado el 24 de agosto de 2026 y, según la API de GitHub, añade un módulo de autenticación del navegador junto con 210 líneas de pruebas de extremo a extremo para el nuevo flujo. La versión etiquetada como dsh-v0.1.2-alpha.1 le siguió el 27 de agosto a las 17:06 UTC.

No establecido: uso. Ni el registro de CVE, ni el aviso de VulnCheck, ni las notas de la versión de DeepSeek describen explotación en la naturaleza, y NVD registra la madurez de explotación como no definida. El modelo EPSS de FIRST otorgó a la vulnerabilidad una probabilidad de explotación del 1,24 % en los siguientes 30 días, en el percentil 68,9, en el feed con fecha del 27 de octubre de 2026. El archivo no registra daños en el mundo real para esta entrada y le asigna una confianza A, bien documentada, con fuentes primarias que coinciden.

Las fechas, incluidos dos informes que llegaron primero

Dos desarrolladores llegaron a la misma conclusión antes de que hubiera un CVE al que señalar. The Hacker News informa de una publicación en el propio foro de debate del proyecto, del 13 de agosto de 2026, que muestra un proceso aún confinado por el sandbox alcanzando la interfaz local y cambiando la sesión a danger-full-access, con la salida de las pruebas, y de una segunda publicación, del 14 de agosto, que enumera las solicitudes que esa interfaz aceptó sin credenciales. La segunda publicación también señalaba que el proyecto no contaba con ningún archivo de política de seguridad ni con una vía privada para notificar una vulnerabilidad; The Hacker News lo comprobó el 9 de septiembre y descubrió que el archivo de política de seguridad seguía faltando.

La cronología de OX Security sitúa su informe a VulnCheck el 24 de agosto de 2026, la misma fecha que GitHub registra para el commit de corrección. El mensaje del commit no dice nada sobre el informe, y el relato público de OX Security, tal como lo describe The Hacker News, no menciona las publicaciones anteriores de la comunidad. Que los dos acontecimientos del 24 de agosto estuvieran relacionados es algo que el registro público no afirma, y este artículo no lo da por sentado.

El intervalo entre la corrección y la divulgación no es inusual. La nota de Cloud Security Alliance registra que OX Security confirmó la corrección el 30 de agosto, nueve días antes de que VulnCheck publicara el CVE.

Dónde se aplicó la corrección y dónde no

La etiqueta de GitHub y el registro de paquetes no avanzaron al mismo tiempo, y esa es la parte que vale la pena saber si instalaste el harness tal como sugieren sus instrucciones. El paquete de línea de comandos, @deepseek-ai/dsh, publicó 0.1.1-rc.2 el 21 de agosto de 2026 y luego nada hasta 0.1.2-alpha.2 el 30 de agosto. La versión 0.1.2-alpha.1, la que el CVE identifica como la corrección, está totalmente ausente del registro, así que la primera versión corregida que se pudo instalar llegó tres días después de la corrección. Los metadatos del registro npm se consultaron para este artículo el 28 de octubre de 2026; The Hacker News informó de la misma brecha el 9 de septiembre.

Las notas de la versión no lo presentaron como una versión de seguridad. Entre cambios rutinarios, indican que la interfaz web ahora requiere autenticación con token de un solo uso para el acceso a la red, sin referencia a CVE ni aviso de seguridad, y The Hacker News no encontró ningún aviso de seguridad en la lista de avisos del repositorio el 9 de septiembre. El mecanismo, tal como lo describe la Cloud Security Alliance: el arnés imprime un token de un solo uso al iniciar, el navegador intercambia ese token por una cookie firmada y cada llamada posterior debe presentar la cookie; la confianza está vinculada a un secreto emitido al inicio del proceso en lugar de a un origen de red declarado.

Las compilaciones de terceros son el cabo suelto. Los wrappers de escritorio incluyen su propia copia del harness, así que la versión que ejecuta un usuario es elección del mantenedor del wrapper; The Hacker News encontró una compilación de Windows fijada a 0.1.1-rc.2 a finales de agosto que pasó a 0.1.3-alpha.1, que incluye la corrección, el 6 de septiembre.

El sandbox en sí no ha cambiado. Al leer la referencia de línea de comandos de 0.1.2-rc.1, The Hacker News encontró la misma afirmación de que los accesos de lectura y de red no están confinados, y descubrió que el shell del agente sigue recibiendo la dirección de la interfaz. Ninguna fuente de ese reportaje indica si un agente que trabaje dentro de su espacio de trabajo aún puede obtener una sesión válida con el nuevo esquema, una cuestión que la propia documentación del parche deja abierta.

Lo que recomiendan las fuentes del registro

• Considere afectada cualquier instalación de 0.1.1-rc.2 o anterior, independientemente de cómo se haya empaquetado, incluida una copia integrada en un contenedor de escritorio.

• Instala la versión 0.1.2-alpha.2 o posterior desde npm; la versión más reciente en el registro el 27 de octubre de 2026 era la 0.2.2-alpha.2.

• Si no puede actualizar, detenga la interfaz web cuando no esté en uso y elimine cualquier túnel, proxy o reenvío de puerto que llegue al puerto 3080.

Compruebe si se puede acceder al puerto 3080 desde cualquier lugar que no sea loopback, incluidos el reenvío de puertos de contenedores, los proxies inversos y los túneles SSH.

• Registre a nivel del arnés los cambios de escalado de privilegios y de modo de aprobación, porque el ataque funcionó al hacer que una escalada no autorizada pareciera una actividad rutinaria.

Los cinco provienen de la nota de Cloud Security Alliance y de la cobertura de The Hacker News; el propio registro CVE no incluye ninguna orientación de remediación más allá de la versión corregida.

Por qué la Cloud Security Alliance lo interpreta como un patrón

La nota de Cloud Security Alliance sitúa este CVE junto a otros dos fallos de contención de agentes de programación que documentó en 2026: GuardFall, el 1 de julio, en el que se pudo inducir a diez de once agentes de programación de código abierto populares a ejecutar comandos de shell que sus barreras de protección estaban diseñadas para bloquear, y los hallazgos sobre el traspaso de confianza del 22 de julio, en los que un agente confinado escribió un archivo que posteriormente ejecutó un componente de confianza situado fuera del sandbox. La nota es explícita en que los tres provienen de su propia investigación y no de un estudio exhaustivo del mercado, y que no está establecido si el patrón se generaliza más allá de los agentes que examinó. Lo que sí sostiene es que los fallos se sitúan en capas diferentes —las barreras de control de comandos, la confianza aguas abajo y, ahora, la autenticación del plano de control— y por eso recomienda tratar la arquitectura de sandbox como una cuestión de adquisición y no como un requisito ya cumplido.

La propia documentación de seguridad de DeepSeek no contradice esa interpretación. El archivo SAFETY.md del repositorio indica que el software «no ha sido sometido a una auditoría de seguridad y no debe considerarse seguro ni listo para producción», y que el aislamiento (sandboxing), los mensajes de aprobación y los controles de permisos «no garantizan el aislamiento ni evitan daños». La brecha de autenticación que permitía a un agente salir a través de la API de control está cerrada en las compilaciones actuales. La asimetría que hizo breve esa salida —un límite alrededor de las escrituras y nada alrededor de la red— sigue siendo una limitación declarada del sandbox y no un defecto que el parche se propusiera corregir.