Vulnerabilidad crítica en AIT-GUI de NASA/JPL: comandos y scripts expuestos sin autenticación

La falla afecta a la consola operativa AMMOS

El 22 de agosto de 2026 se hizo pública una vulnerabilidad crítica en el componente AIT-GUI de AMMOS Instrument Toolkit, un framework de código abierto desarrollado por NASA/JPL para operaciones multimisión.

AIT-GUI proporciona a los operadores una consola accesible desde el navegador. A través de esta interfaz es posible interactuar con instrumentos científicos y vehículos espaciales, enviar comandos, ejecutar secuencias y recopilar los datos devueltos por los sistemas controlados.

La vulnerabilidad está identificada como GHSA-p9r8-2q67-fp86. El problema tiene una severidad Critical y una puntuación CVSS de 9.4. La corrección está disponible en la versión AIT-GUI 2.5.2.

No se han divulgado detalles sobre las versiones vulnerables. Por tanto, las instalaciones que no utilicen la versión corregida deben considerarse en riesgo hasta verificar la actualización.

Servidor expuesto en todas las interfaces de red

Según el análisis de Cycode, AIT-GUI inicia un servidor HTTP sin autenticación, autorización, gestión de sesiones ni protecciones frente a ataques de Cross-Site Request Forgery, conocidos como CSRF.

El problema no se limita a la ausencia de un inicio de sesión. La aplicación lee la configuración del host, pero posteriormente no la utiliza para determinar la dirección de escucha del servicio. En su lugar, el servidor realiza el binding en:

0.0.0.0

Esta configuración hace que el servicio sea accesible a través de todas las interfaces de red disponibles. Por tanto, incluso una configuración como host: localhost, que debería limitar el acceso al equipo local, no impide la exposición a la red accesible desde la instancia.

Un atacante que pueda alcanzar el puerto del servicio puede interactuar directamente con las rutas operativas. No es necesariamente necesario disponer de una cuenta.

Los endpoints permiten ejecutar comandos, secuencias y scripts

El endpoint más delicado es:

POST /cmd

El valor incluido en el campo command se interpreta y se reenvía directamente al bus de comandos. En el flujo descrito por Cycode no se observan mecanismos suficientes de autenticación, validación ni controles intermedios que impidan el envío de comandos arbitrarios.

También están expuestos otros endpoints con funciones operativas:

POST /seq
POST /script/run
POST /scripts/load

Las rutas /seq y /script/run construyen las rutas de los archivos concatenando datos controlados por el usuario con el directorio raíz previsto por la aplicación. No existe un confinamiento coherente de las rutas.

Por tanto, una entrada como:

../../../../something

puede resolverse fuera del directorio autorizado. Esto introduce un escenario de path traversal, con posible acceso a archivos ubicados en otras partes del sistema de archivos o con la ejecución de scripts no previstos por el operador.

El código ya contiene una lógica adecuada para impedir la salida del directorio permitido. Sin embargo, según los investigadores, el control se aplica a la ruta /scripts/load y no se reutiliza de forma uniforme en /seq y /script/run.

El riesgo persiste incluso detrás de un firewall

Una instalación expuesta puede permitir que un atacante:

• envíe comandos arbitrarios a instrumentos o vehículos mediante /cmd;
• ejecute secuencias mediante /seq;
• inicie scripts en el servidor con /script/run;
• intente acceder a archivos fuera del directorio previsto mediante rutas manipuladas.

La ausencia de protecciones CSRF amplía aún más la superficie de ataque. Un operador que utilice AIT-GUI desde su navegador podría visitar una página o seguir un enlace malicioso dentro del mismo entorno.

La página maliciosa podría inducir al navegador a enviar solicitudes a la consola. En determinadas condiciones, estas solicitudes pueden enviarse sin una verificación previa con el servicio destinatario, eludiendo de facto la expectativa de que una solicitud operativa deba generarse desde la interfaz legítima.

Por este motivo, el firewall no constituye una defensa suficiente. Si el navegador del operador puede acceder a AIT-GUI y carga contenido malicioso, el ataque puede producirse incluso sin que el atacante tenga acceso directo e interactivo al puerto de la consola.

La ausencia de autenticación también dificulta atribuir cada comando a un usuario concreto. Las instalaciones expuestas antes de la corrección deben considerarse potencialmente comprometidas, aunque no se detecten de inmediato errores visibles.

El análisis produjo pruebas de explotación funcionales

Cycode combinó análisis de código asistido por inteligencia artificial con verificación manual. Las herramientas automatizadas buscaron, entre otros elementos, rutas capaces de modificar el estado sin autenticación, datos de solicitudes enviados a subprocesos sin sanitización y configuraciones que se leen pero posteriormente se ignoran.

A continuación, los investigadores reprodujeron operativamente las anomalías identificadas. La actividad permitió crear pruebas de concepto funcionales, incluida una demostración de CSRF ejecutada con un navegador headless real.

Durante esta prueba se registraron cero preflight de red. El dato demuestra que el escenario no depende necesariamente de una autorización previa por parte del servicio expuesto: el navegador puede transmitir determinadas solicitudes cross-origin sin realizar la comprobación preliminar que normalmente se asocia a las solicitudes más restrictivas.

Cycode considera confirmadas las vulnerabilidades reproducidas operativamente y las distingue de los resultados que solo surgen del análisis estático del código.

Qué deben hacer los administradores

La medida principal es actualizar inmediatamente todas las instalaciones a AIT-GUI 2.5.2. La simple restricción del acceso mediante un firewall no debe considerarse una solución definitiva.

Los administradores también deberían:

1. verificar que el puerto de la consola no sea accesible desde redes no confiables;
2. revisar los registros relacionados con comandos, secuencias y scripts ejecutados antes de la actualización;
3. analizar cada instancia expuesta como potencialmente comprometida;
4. añadir autenticación y protecciones CSRF a /cmd, /seq y /script/run;
5. asegurarse de que el servidor utilice realmente el host configurado, en lugar de realizar el binding en 0.0.0.0;
6. aplicar a /seq y /script/run la misma lógica de confinamiento de rutas ya presente en /scripts/load.

No se sabe si GHSA-p9r8-2q67-fp86 se ha incluido en el catálogo KEV de CISA, ni hay información sobre posibles plazos operativos establecidos por la agencia. Tampoco se indican precedentes recientes del mismo proveedor en el catálogo.