Vulnerabilidad DeepSeek Harness: CVE 9.4 y el parche

En pocas palabras: La vulnerabilidad CVE-2026-82533 (CVSS 9.4) mostró que el sandbox de DeepSeek Harness frenaba escrituras de archivos pero dejaba abierta la red local: un agente podía desactivarlo con un solo comando. DeepSeek lo corrigió en la 0.1.2-alpha.1 el 27 de agosto de 2026.

La vulnerabilidad DeepSeek Harness (CVE-2026-82533, CVSS 9.4) dejaba que un agente de código encerrado en su sandbox lo desactivara con un solo comando de shell. DeepSeek la corrigió en la versión 0.1.2-alpha.1 el 27 de agosto de 2026 y VulnCheck publicó el CVE el 8 de septiembre.

DeepSeek Harness (dsh) es el entorno open source y local-first con el que DeepSeek corre agentes de código. Según OX Security, tiene una interfaz web respaldada por una API HTTP local en 127.0.0.1:3080 y ejecuta los comandos del agente dentro de un sandbox del sistema operativo. Salió en agosto de 2026 como public preview, con licencia MIT y código en TypeScript, y se apoya en el framework Cordis, donde cada pieza es un plugin.

¿Qué es el CVE-2026-82533 y cómo escapa un agente del sandbox de DeepSeek Harness?

El CVE-2026-82533 es una falla de confianza en la API de control de dsh. La API decidía si un pedido era de fiar leyendo el encabezado Host que manda el propio cliente, sin mirar la dirección real de la conexión. Como el sandbox dejaba abierta la red loopback, el agente encerrado podía llamar a esa API y subirse los permisos.

Según OX Security, la cadena tiene tres eslabones:

• Una API sin autenticación. La función isTrustedApiRequest aceptaba cualquier pedido cuyo Host fuera una dirección loopback o estuviera en una lista de hosts confiables. Un navegador no puede mentir con ese encabezado, pero un cliente como curl sí.
• Un sandbox que cierra una puerta y deja otra abierta. Los perfiles de bubblewrap, Landlock y Seatbelt restringían la escritura de archivos. En bubblewrap, el argumento era –unshare-pid sin –unshare-net, así que la red se compartía con el equipo.
• Comandos de shell sin aprobación. Las llamadas normales a bash no pedían confirmación, así que el agente no tenía que pedirle permiso a nadie.

El resultado: un solo curl desde adentro del sandbox elevaba la sesión a danger-full-access con aprobación en “never”. Cada comando posterior corría sin encierro y sin preguntas. El log de sesión ni siquiera mostraba un evento approval/request, y el cambio de política quedaba registrado como hecho por un usuario (source kind user). El harness no distinguía entre el shell del agente y vos frente al teclado.

Ejemplo hipotético (es una ilustración armada a partir del tipo de ataque que describe Cloud Security Alliance, no un caso real): abrís un repo que no es tuyo y le pedís al agente que lo resuma. El README trae una instrucción escondida. El agente corre un curl contra la API local. La API cree que le habla un cliente legítimo porque el encabezado dice localhost. La sesión pasa a danger-full-access y, desde ahí, cada comando corre sin sandbox y sin que nadie te pregunte nada. OX aclara que la única condición previa era que el agente ejecutara un comando inducido por texto del atacante, justo el tipo de entrada no confiable que el sandbox existe para contener.

La puerta de red remota era otra historia. Si el puerto quedaba accesible por un túnel, un reverse proxy, un SSH forward o el port forwarding de un editor, un atacante sin autenticación podía controlar el agente y bajar todas las conversaciones guardadas, sin API key. Cubrimos ese tema en detalle en el cliente de escritorio DSH Desktop.

¿Qué versiones están afectadas y cuándo se corrigió?

Están afectadas las versiones 0.1.1-rc.2 y anteriores de dsh, según OX Security. La corrección salió el 27 de agosto de 2026 en la 0.1.2-alpha.1, a tres días del aviso a VulnCheck.

• 13 y 14 de agosto: usuarios publicaron la técnica en las discusiones de GitHub de DeepSeek, según CSA.
• 24 de agosto: OX Research reportó la falla a VulnCheck, que actúa como CNA.
• 27 de agosto: DeepSeek lanzó la 0.1.2-alpha.1.
• 30 de agosto: OX volvió a probar y confirmó la remediación.
• 8 de septiembre: se publicó el CVE.

Los números son rápidos desde el aviso formal (3 días) y menos lindos desde que la comunidad mostró el truco (unos 14 días, cálculo del artículo de dev.to). Ojo: en ese lapso el método estaba a la vista de cualquiera.

¿Cómo arregló DeepSeek el problema? Según CSA, reemplazó la confianza por Host con un esquema de token y cookie: dsh imprime un token de un solo uso al arrancar, el cliente lo cambia por una cookie firmada y la API exige esa cookie en cada llamada. Con eso la confianza depende de tener un secreto y no de lo que el cliente dice ser.

Una inconsistencia para anotar: OX habla de la 0.1.2-alpha.1 como versión corregida, pero la sección de acciones de CSA menciona “0.1.2-alpha.2 o posterior”. Con lo que tengo no puedo decir cuál es la errata. Lo prudente es instalar la alpha.1 o algo más nuevo y revisar el changelog oficial.

¿Qué significa que en DeepSeek Harness todo sea un plugin?

Significa que el adaptador de modelo, el registro de herramientas, el log de sesión y hasta el loop del agente son plugins que se reemplazan por configuración. Lo dice la documentación de arquitectura, que agrega: “There is no privileged core to patch”.

La base es Cordis, un proyecto abierto con licencia MIT que existe desde 2022 y tiene 9.108 estrellas y 576 forks según el artículo de dev.to. Si querés ver el árbol real de tu máquina, el comando es dsh –profile web –dump-config, y cada fila que imprime se puede reemplazar con un patch propio (por ejemplo en cordis.patch.yml). Tema relacionado: cómo armar un plugin dsh desde cero.

La adopción es grande. El mismo artículo reporta 246.721 estrellas y 29.616 forks en GitHub al 10 de octubre de 2026, y CSA contaba unas 215.000 estrellas pocas semanas después del lanzamiento. Son cifras de GitHub que cambian todos los días, así que tomalas como una foto.

Acá viene mi lectura, y la marco como tal: sin núcleo especial no hay muro especial. El autor del artículo de dev.to dice algo parecido, que un plugin llega a todo lo que llega el programa. Pero ese no fue el origen del CVE. La falla vino de un chequeo por encabezado y de una red loopback abierta, no de Cordis. La arquitectura sí agranda lo que está en juego cuando instalás plugins ajenos, y eso conviene tenerlo presente.

¿Es un problema solo de DeepSeek o de todos los agentes de código?

No hay evidencia para decir que todo el sector está roto. CSA documentó tres fallas de sandbox en agentes de código durante 2026 con causas distintas, y aclara que todavía no se sabe si reflejan un patrón de la industria o solo los casos que los investigadores eligieron mirar.

• GuardFall (junio): 10 de 11 agentes open source populares ejecutaban comandos que sus propias defensas debían frenar, porque inspeccionaban el texto crudo antes de que el shell quitara comillas y expandiera variables.
• Trust handoff (julio): Pillar Security mostró que en varios agentes de código comerciales no hacía falta romper el sandbox. El agente escribía un archivo y un componente confiable de afuera (extensión de IDE, Git, task runner, Docker daemon) lo ejecutaba sin revisarlo.
• DeepSeek Harness (septiembre): la falla está en la capa de control, no en el sandbox en sí.

Algo que ayuda a ponerlo en perspectiva: la documentación de DeepSeek ya decía que su sandboxing “does not guarantee isolation or prevent damage”, según CSA. La frase es honesta, pero escribirla no garantiza que quien instala la herramienta la haya leído. Con un “muro” que el propio fabricante dice que no garantiza nada, el trabajo de medir el riesgo pasa a ser tuyo. Ya lo cubrimos antes en nuestra nota sobre DeepSeek Harness como alternativa open source.

¿Cómo usar DeepSeek Harness con más seguridad?

Actualizá a la 0.1.2-alpha.1 o posterior y no expongas el puerto de control a la red. Con eso cerrás las dos puertas descritas por OX. El resto son hábitos que aplican a cualquier agente con shell.

• Verificá la versión de todo lo que embebe dsh. CSA advierte que wrappers de escritorio e integraciones de IDE pueden traer una copia vieja, independiente del release upstream.
• No reenvíes el puerto. El puerto 3080 se abre por defecto solo en loopback. Túneles, reverse proxies, SSH forwards y port forwarding del editor son lo que lo exponía. En desktop, la documentación indica que el puerto lo asigna el sistema operativo por defecto.
• Instalá solo desde el GitHub oficial. El artículo de dev.to recoge el aviso de un usuario sobre sitios que reempaquetan dsh con modificaciones y se posicionan por SEO arriba del sitio de DeepSeek. Es un reporte de usuario, no una verificación.
• Leé el código de los plugins de terceros antes de instalarlos. Los oficiales que muestra la web (agent teams, scheduled tasks, voice input) llevan etiqueta “Experimental”.
• Revisá la telemetría del desktop. Según el artículo de dev.to, un usuario reportó que viene activada por defecto y que se apaga con cordis.patch.yml antes del primer arranque. No lo confirmé en documentación oficial.
• Probá en un entorno aparte. Un VPS dedicado, por ejemplo de donweb.com, sin credenciales sensibles ni claves SSH de producción, achica el daño si algo sale mal. Eso sí: no reenvíes ahí el puerto de control.

Una propuesta de verificación mía, no de las fuentes: después de actualizar, intentá abrir la interfaz sin pasar por el token que imprime el arranque. Si entra sin pedirlo, no estás corriendo la versión corregida. Y desde otra máquina de tu red, comprobá que el puerto de control no responda.

El producto sigue en preview. El artículo de dev.to cita al README, que avisa que habrá cambios incompatibles, así que no lo pongas como base de nada que no puedas romper.

Criterios para decidir qué hacer según tu situación

Estos criterios son una síntesis propia a partir de lo que describen OX y CSA, no una recomendación oficial de los autores.

• Si no podés actualizar ya: CSA indica que desactivar la interfaz web local elimina la superficie expuesta hasta aplicar el parche. Además, auditá que el puerto de control no sea accesible desde fuera del loopback.
• Si el agente lee material que no escribiste (repos ajenos, issues, READMEs): es el escenario que OX usó como condición del ataque. Corré dsh en un entorno sin claves ni credenciales valiosas y revisá lo que el agente ejecuta.
• Si compartís el equipo con túneles o port forwarding: es la condición que convertía el fallo local en remoto. Revisá qué puertos tenés reenviados antes de arrancar el harness.
• Si necesitás estabilidad: el proyecto está en preview y su README anuncia cambios incompatibles. Tiene más sentido para pruebas que como base de un flujo crítico.
• Si valorás la personalización: el modelo de plugins la ofrece, pero cada plugin de terceros amplía lo que podría salir mal. Instalá solo lo que hayas leído.

Ejemplo hipotético (ilustrativo, no es un caso real): en un equipo de cinco personas, una de ellas instaló dsh hace semanas a través de un wrapper de escritorio, y otra lo usa con un reenvío de puerto del editor para trabajar desde otra máquina. Aplicando los criterios de arriba, lo primero sería comprobar qué versión de dsh trae el wrapper, y lo segundo cerrar ese reenvío, porque es justo la precondición de la variante remota. Recién después tendría sentido discutir qué plugins instalar.

¿Qué está confirmado y qué no?

Confirmado, según OX Security y CSA:

• CVE-2026-82533, CVSS 9.4, con versiones afectadas 0.1.1-rc.2 y anteriores.
• El mecanismo de escape, probado por OX en una instalación por defecto con un control en el que el sandbox bloqueaba la escritura fuera del workspace antes del escape.
• Corrección el 27 de agosto de 2026 y reverificación de OX el 30 de agosto.

Sin confirmar o con matices:

• Si las tres fallas de CSA reflejan un patrón de toda la industria.
• El nombre exacto de la versión corregida (alpha.1 según OX, alpha.2 mencionada por CSA).
• La telemetría por defecto en desktop y el reempaquetado con SEO, que provienen de comentarios de usuarios recogidos en el artículo de dev.to.
• Las cifras de estrellas y forks, que vienen de un artículo secundario y cambian a diario.
• Explotación en entornos reales: ninguna de las fuentes que revisé la reporta, lo que no prueba que no haya ocurrido.

¿Alguien verificó el parche de forma independiente? Sí: OX, la misma firma que encontró el problema, lo hizo el 30 de agosto. Es una confirmación del descubridor, no de un tercero. Complementá con el runtime de agentes basado en plugins.

Errores comunes al usar agentes de código con sandbox

• Tratar el sandbox como la única barrera. La propia documentación dice que no garantiza aislamiento. Corrección: dejá fuera del equipo del agente las claves SSH, credenciales cloud y tokens de registries.
• Dar por segura la red loopback. Este CVE existe justo por eso. Corrección: pedí que el sandbox restrinja también la red, no solo los archivos.
• Actualizar el CLI y olvidarse del resto. Wrappers y extensiones pueden traer una copia vieja. Corrección: revisá la versión de cada herramienta que embeba dsh.
• Abrir el puerto “para usarlo desde el celu”. Un túnel o un port forward convierte un problema local en uno remoto. Corrección: dejalo en loopback.
• Instalar plugins o binarios por lo que sale primero en Google. Corrección: bajá del GitHub oficial y leé el código antes de montar un plugin.

Preguntas Frecuentes

¿Qué es el CVE-2026-82533 de DeepSeek Harness?

Es una vulnerabilidad crítica (CVSS 9.4) publicada el 8 de septiembre de 2026 que dejaba a un agente confinado desactivar su propio sandbox. La API de control local confiaba en el encabezado Host enviado por el cliente en lugar de verificar la conexión real.

¿Cómo se escapa un agente de IA del sandbox de DeepSeek Harness?

Con un solo comando de shell que llama a la API local del harness desde adentro del sandbox. Esa llamada elevaba la sesión a danger-full-access con aprobaciones en “never”, y los comandos siguientes corrían sin restricciones ni confirmaciones.

¿Qué versión de DeepSeek Harness corrige la vulnerabilidad?

La 0.1.2-alpha.1, publicada el 27 de agosto de 2026, según OX Security. Las versiones 0.1.1-rc.2 y anteriores están afectadas. CSA menciona “alpha.2 o posterior” en un pasaje, así que conviene instalar lo más reciente y revisar el changelog.

¿Es seguro usar DeepSeek Harness y sus plugins?

Con la versión corregida, el puerto sin exponer y plugins revisados, el riesgo baja, pero no desaparece. La propia documentación de DeepSeek aclara que su sandbox no garantiza aislamiento, y el proyecto sigue en preview con cambios incompatibles anunciados.

¿Qué significa que en DeepSeek Harness todo sea un plugin?

Que el adaptador de modelo, el registro de herramientas, el log de sesión y el loop del agente son plugins reemplazables por configuración, sobre el framework Cordis. No hay un núcleo privilegiado que parchear, y por eso un plugin de tercero se monta al lado de los demás.

Conclusión

La vulnerabilidad DeepSeek Harness muestra que un sandbox que restringe una sola vía (archivos) y deja abierta otra (loopback) protege menos de lo que parece, y que la capa de control del agente también es superficie de ataque. DeepSeek respondió rápido una vez avisado, aunque la técnica estuvo pública unos 14 días antes del parche.

Qué hacer: actualizá a la 0.1.2-alpha.1 o posterior, revisá las copias embebidas, no expongas el puerto de control, instalá solo desde el repo oficial y leé los plugins ajenos. Y si te tienta el “todo es un plugin”, recordá que la flexibilidad y la superficie de ataque vienen juntas.

Fuentes

• DeepSeek Harness – página oficial del producto
• DeepSeek Harness Architecture – documentación oficial en GitHub
• OX Security – análisis técnico del CVE-2026-82533
• Cloud Security Alliance – nota de investigación sobre el escape de sandbox
• dev.to – análisis a dos meses del lanzamiento (escrito con IA bajo revisión humana, según el propio artículo)