QVD-2026-57410: cómo una cabecera HTTP falsificada puede abrir la puerta a la ejecución remota de comandos

QVD-2026-57410 es una vulnerabilidad crítica reportada en DeepSeek Harness (DSH) 0.1.1-rc.2. Informes vinculados a QiAnXin la describen como una vulnerabilidad de ejecución remota de comandos (RCE) sin autenticación, con una puntuación de 9,8 sobre 10 en CVSS 3.0. El problema central es que la capa /api puede basar su decisión de confianza en la cabecera HTTP Host, un valor controlado por el cliente que no debe utilizarse como sustituto de la autenticación. 1924

El riesgo real depende en gran medida de la forma en que se haya desplegado el servicio. La documentación de DeepSeek indica que el comando web inicia la interfaz en 127.0.0.1:3080 por defecto, lo que limita el acceso remoto directo. La exposición se vuelve mucho más peligrosa cuando el servicio se publica en una interfaz distinta de loopback o se reenvía mediante Docker, un proxy inverso, un túnel, una VPN, una red local o un sistema de ingress. 1118

Cómo funciona el bypass de la cabecera Host

El diseño afectado intenta distinguir las solicitudes locales de las remotas a partir de la información del host de la petición. Sin embargo, la cabecera Host la proporciona el propio solicitante y puede falsificarse.

Un atacante que pueda alcanzar el servicio puede enviar un valor que parezca corresponder a una conexión local. DSH podría entonces interpretar la solicitud como confiable y permitir el acceso a operaciones que deberían estar restringidas a la máquina local. Los informes describen este comportamiento como una evasión del límite de confianza basado en loopback de DSH. 1924

A grandes rasgos, la cadena de ataque reportada sería la siguiente:

1. Acceder a un endpoint web o de administración de DSH expuesto.
2. Enviar una solicitud con una cabecera Host falsificada y con apariencia local.
3. Eludir la restricción de /api destinada a proteger operaciones internas.
4. Invocar funciones RPC restringidas.
5. Registrar o utilizar una ruta de proveedor de modelos controlada por el atacante.
6. Aprovechar las capacidades del agente de DSH para ejecutar comandos en el sistema anfitrión. 1920

Por eso el fallo es más grave que un simple problema de enrutamiento o una filtración de información: el bypass puede alcanzar funcionalidades diseñadas para operar un agente de IA con capacidades sobre el sistema.

Por qué puede convertirse en ejecución remota de comandos

DeepSeek define Harness como software experimental en fase de vista previa para desarrolladores y advierte que no ha sido sometido a una auditoría de seguridad. Su aviso de seguridad señala que el proyecto puede ejecutar código y comandos generados por modelos, además de acceder a la red, los procesos, las credenciales y los archivos que estén disponibles para él. 4

El subsistema LLM también permite registrar proveedores y descubrir modelos, incluida la operación remota discoverModels. 23 En la cadena de explotación descrita por los informes, un proveedor controlado por el atacante puede aportar la entrada necesaria para alcanzar las capacidades de ejecución de comandos del agente. 19

Una explotación exitosa no implica automáticamente obtener acceso de root. Los comandos se ejecutarían con los permisos del proceso que ejecuta DSH. Aun así, esos permisos podrían bastar para leer o modificar archivos accesibles, utilizar credenciales o claves API disponibles, iniciar procesos, alterar datos de la aplicación o establecer conexiones salientes.

El impacto final dependerá del despliegue: por ejemplo, de si el servicio tiene permisos excesivos sobre el sistema de archivos, se ejecuta en un contenedor privilegiado, dispone de un socket Docker montado o puede acceder a credenciales de servicios en la nube. La información disponible no demuestra que todas las instalaciones impliquen automáticamente el control total del equipo anfitrión.

Qué despliegues están más expuestos

Los operadores deberían revisar con prioridad las siguientes configuraciones:

• DSH enlazado a 0.0.0.0 o a cualquier otra dirección que no sea de loopback.
• Docker u otro runtime de contenedores publicando el puerto 3080 más allá del equipo local.
• Un proxy inverso que reenvíe la API de administración a Internet o a una red local no confiable.
• Un túnel, una VPN o un sistema de ingress que haga accesible el servicio a usuarios sin autenticación sólida.
• Proxies que acepten cualquier valor de Host enviado por el cliente o lo reenvíen aguas arriba sin modificarlo.

Que un servicio sea “interno” no constituye por sí solo un control de autorización. Cualquier atacante que pueda llegar al endpoint e influir en las cabeceras relevantes puede intentar eludir la barrera.

PoC público, estado de CVE y pruebas de explotación

Varios informes indican que ya hay material de prueba de concepto (PoC) o detalles técnicos públicos para QVD-2026-57410. 192027 Esto eleva la urgencia de contener el problema, pero la existencia de una PoC no equivale a una prueba de que una instalación concreta haya sido comprometida.

Según la información proporcionada, no se había observado explotación masiva en entornos reales ni existían pruebas que vincularan el fallo con un actor de amenazas o una campaña conocida en el momento de la divulgación. 1924 Se trata de una fotografía limitada del momento de la publicación, no de una garantía de seguridad. Las instancias expuestas deberían investigarse en busca de solicitudes anómalas, registros inesperados de proveedores, procesos nuevos y conexiones salientes inusuales.

QVD-2026-57410 es un identificador QVD, no un identificador CVE. El registro CVE-2026-57410 de la NVD corresponde a una vulnerabilidad no relacionada de escalada de privilegios en MailerPress. 17

Qué deberían hacer los operadores

1. Eliminar primero la exposición de red

Deja de publicar la interfaz de administración y la API de DSH en Internet. Enlázalas a loopback o a una red de gestión dedicada. Si necesitas administración remota, utiliza una VPN controlada o un bastion host.

2. Restringir el acceso en todas las capas

Aplica reglas de firewall, grupos de seguridad en la nube, redes de contenedores y proxies inversos que permitan únicamente el acceso desde orígenes expresamente confiables. No dependas de una ruta interna ni de una cabecera con apariencia local como prueba de identidad.

3. Validar y sobrescribir las cabeceras del proxy

Rechaza en el proxy perimetral los valores de Host que no estén permitidos. Cuando sea necesario reenviar la solicitud, sobrescribe la cabecera Host aguas arriba con un valor fijo y conocido; no la transmitas ciegamente desde el cliente. Trata las cabeceras de IP reenviada como confiables solo cuando procedan de un proxy bajo tu control.

4. Añadir autenticación independiente de Host

Protege la administración y las operaciones RPC internas con autenticación y autorización reales, independientes de la cabecera Host y de las afirmaciones sobre la dirección de origen. Entre las opciones posibles están una pasarela con autenticación sólida, mTLS y controles de acceso por operación. La validación de Host puede servir para el enrutamiento, pero nunca debe ser el único control de identidad.

5. Reducir el riesgo de descubrimiento de proveedores y de conexiones salientes

Desactiva o restringe llm.discoverModels cuando no sea necesario. Si el descubrimiento de proveedores es imprescindible, utiliza una lista permitida de endpoints y controles de egreso. Bloquear el acceso a destinos internos sensibles y a servicios de metadatos de la nube puede limitar el impacto si una ruta de descubrimiento de proveedores se utiliza como primitiva de solicitudes del lado del servidor. La documentación del LLM de DSH confirma que el registro de proveedores y el descubrimiento de modelos son capacidades expuestas. 23

6. Comprueba la corrección en los avisos oficiales

Las fuentes proporcionadas identifican como afectada la versión 0.1.1-rc.2 y muestran actividad posterior de lanzamientos, pero no establecen que una compilación posterior concreta corrija esta vulnerabilidad. Consulta las notas de lanzamiento y los avisos de seguridad actuales de DeepSeek para encontrar una corrección confirmada antes de considerar suficiente cualquier actualización. El propio aviso de seguridad del proyecto sigue describiendo Harness como experimental y no apto para producción. 410

7. Investiga y rota credenciales si hubo exposición

Revisa los registros del proxy inverso y de DSH en busca de solicitudes anómalas a /api, valores de Host falsificados con apariencia local, registros inesperados de proveedores, lanzamientos de procesos, cambios de archivos y conexiones salientes inusuales.

Rota las credenciales a las que pudiera acceder el proceso de DSH. Si encuentras indicios de ejecución de comandos o persistencia, aísla y reconstruye el equipo o contenedor afectado en lugar de asumir que reiniciar el servicio eliminó la intrusión.