Protegiendo GitLab AI Gateway contra la ejecución remota de código

Las grandes empresas gastan millones para aislar sus cargas de trabajo de IA tras cortafuegos privados y pasarelas autohospedadas. Esperan un control total sobre su flujo de datos y un perímetro reforzado contra amenazas externas. La explotabilidad real de la versión 19.4 de GitLab AI Gateway demuestra que incluso los entornos más aislados siguen siendo vulnerables a fallos de entrada simples. Un único usuario conectado con acceso a Duo Agent Platform puede eludir el entorno de aislamiento (sandbox) que supuestamente debe contener las instrucciones de IA. Este escape conduce directamente a la ejecución arbitraria de comandos en el servidor que gestiona la conexión de la organización con los modelos de lenguaje de gran tamaño.

He pasado años analizando cómo los desarrolladores tratan los motores de plantillas como zonas seguras. Existe la idea errónea común de que, si un usuario ya está autenticado, el riesgo de un escape del sandbox es secundario. Esta mentalidad es peligrosa. En el caso de CVE-2026-90970, GitLab calificó el fallo con un 9.9 sobre 10 en la escala CVSS. Esa puntuación es un indicador claro de que la comunidad de seguridad considera esto como un fallo crítico para la misión. El fallo no es una sutil corrupción de memoria o un ataque de sincronización complejo. Es un fallo en la plantilla de instrucciones de un flujo personalizado, una función diseñada para automatizar tareas de varios pasos.

El riesgo arquitectónico de las claves de firma sensibles

GitLab AI Gateway actúa como una bóveda digital irrompible para la conexión entre una instancia interna de GitLab y los proveedores externos de IA. Por diseño, esta pasarela contiene claves de firma de JSON Web Tokens (JWT). Estas claves son credenciales sensibles que facilitan la comunicación segura. Si un atacante ejecuta comandos en la pasarela, ya no es solo un usuario dentro de un sandbox. Posee los mismos permisos que el propio servicio de la pasarela. Este nivel de acceso permite a un actor malintencionado interceptar peticiones o potencialmente manipular las respuestas de la IA en las que confían otros desarrolladores de la empresa para la generación de código y el escaneo de seguridad.

Desde una perspectiva de riesgo, el impacto es sistémico. A menudo se elige una pasarela autohospedada específicamente para mantener los datos dentro de un entorno controlado. Cuando esa pasarela se ve comprometida, la misma herramienta destinada a mejorar la privacidad se convierte en una cabeza de puente para una intrusión mayor. La pasarela se conecta a los proveedores de modelos de IA de la organización y a la instancia principal de GitLab. Un compromiso aquí es un compromiso de la relación de confianza entre el entorno de desarrollo y la capa de inteligencia que lo impulsa.

Deconstruyendo el escape del sandbox por inyección de instrucciones

La realidad técnica de este fallo radica en CWE-1336, que cubre la neutralización inadecuada de directivas en plantillas de páginas web. GitLab permite a los usuarios crear flujos personalizados en Duo Agent Platform. Estos flujos utilizan plantillas de instrucciones (prompts) para estructurar cómo la IA procesa la información. Un usuario con acceso legítimo puede diseñar una configuración de flujo que engañe al motor de plantillas para que ejecute código fuera de sus límites previstos. Este es el clásico escape de sandbox. El sistema trata la entrada maliciosa del atacante como un comando en lugar de como datos.

En segundo plano, la pasarela no valida correctamente la estructura de la plantilla de instrucciones. Recuerdo un caso similar que discutí con un hacker ético a través de una conexión de Signal el año pasado. Analizamos un motor de plantillas que permitía a los usuarios llamar a funciones del sistema si anidaban sus corchetes de una manera específica. Fue un simple descuido en el analizador. La historia reciente de GitLab sugiere que este es un tema recurrente. En febrero, parchearon CVE-2026-1868, otro fallo de 9.9 que también involucraba definiciones de flujo manipuladas. La repetición de esta clase de vulnerabilidad indica que la seguridad de las plantillas sigue siendo un obstáculo difícil para las plataformas integradas con IA.

Evaluación de la superficie de ataque para instancias autohospedadas

Solo las organizaciones que alojan su propio AI Gateway necesitan actuar. GitLab gestiona la pasarela para los clientes en GitLab.com y GitLab Dedicated. Hablando proactivamente, esos clientes ya están protegidos porque GitLab actualizó su propia infraestructura antes del aviso público. La carga de la defensa recae ahora sobre los hombros de los administradores de sistemas que gestionan sus propias imágenes de Docker o charts de Helm.

A nivel arquitectónico, la pasarela es un servicio independiente. No se devuelve automáticamente cuando se actualiza la instancia principal de GitLab. Esta separación es importante. Un error común es asumir que una aplicación GitLab Rails parcheada significa un entorno de IA parcheado. La pasarela es una imagen de Docker separada con su propio control de versiones y ciclo de vida. Si ejecuta una versión entre la 18.1.6 y la 19.2.4, o cualquier versión en las líneas 19.3 y 19.4 anteriores a los últimos lanzamientos, es vulnerable.

Pasos de actualización manual para Docker y Helm

El parcheo es la única contramedida eficaz porque GitLab no ha proporcionado una solución alternativa. Para asegurar un despliegue basado en Docker, debe detener el contenedor existente y eliminarlo. Luego, descargue la etiqueta de imagen actualizada. Para la mayoría de los usuarios empresariales, esta será la etiqueta self-hosted-v19.4.1-ee o su equivalente para las líneas 19.2 y 19.3.

Para aquellos que utilizan Kubernetes, el proceso implica actualizar la configuración de la imagen en el chart de Helm. La siguiente tabla resume las rutas de actualización necesarias para las versiones afectadas:

La política de mantenimiento de GitLab generalmente cubre el lanzamiento menor actual y los dos anteriores. En consecuencia, las correcciones están disponibles para las líneas 19.2, 19.3 y 19.4. Si está ejecutando una versión más antigua, como la 19.1, no hay una corrección oficial listada. Esta falta de soporte para versiones antiguas es un detalle granular que los administradores no deben pasar por alto. Ejecutar una versión no compatible de la pasarela es, efectivamente, dejar la bóveda digital abierta.

Limitaciones forenses y ausencia de explotación

A día de hoy, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) indica que la explotación de este fallo es nula. No hay una prueba de concepto pública ni evidencia de explotación activa en el entorno real. Sin embargo, el aviso no proporciona un método para comprobar si una pasarela fue atacada antes de la actualización. Esta falta de visibilidad forense es una brecha significativa. Sin firmas de registro específicas o indicadores de compromiso, los administradores se quedan preguntándose si se accedió a sus claves de firma durante la ventana de vulnerabilidad.

En caso de una brecha que involucre una herramienta como esta, el objetivo suele ser la persistencia sigilosa. Un atacante podría no bloquear la pasarela. En su lugar, podría exportar silenciosamente las claves de firma JWT para facilitar el acceso no autorizado a los modelos de IA más adelante. Por ello, la rotación inmediata de credenciales sensibles después de un parche es una práctica estándar de la industria. Parchear el agujero en el casco del barco es el primer paso, pero también debe comprobar si se arrojó carga por la borda mientras el agujero estaba abierto.

El elemento humano en la seguridad de la IA

A menudo tratamos a la IA como una capa futurista que se asienta sobre nuestro código existente. En realidad, los servicios de IA como GitLab Gateway son solo más software. Están sujetos a las mismas vulnerabilidades de la vieja escuela, como la inyección de comandos y los escapes de plantillas. El cortafuegos humano sigue siendo la primera línea de defensa. Los usuarios que tienen acceso a Duo Agent Platform son los que pueden alcanzar este fallo. Restringir el acceso a estas plataformas solo a quienes estrictamente lo necesiten sigue el principio de privilegio mínimo.

Zero Trust es un portero de club VIP en cada puerta interna. Incluso si un usuario está dentro del edificio, el portero debe verificar sus credenciales antes de dejarlo acercarse a la configuración del motor de plantillas. Si su organización permite que cada desarrollador cree flujos de IA personalizados sin supervisión, está aumentando su superficie de ataque. La complejidad de estas integraciones de IA hace que el control de acceso granular sea un requisito en lugar de una sugerencia.

Conclusiones para la mitigación inmediata

Para abordar este fallo crítico, los administradores deben seguir una secuencia específica de acciones. Primero, identifique la versión exacta de la imagen de AI Gateway que se está ejecutando actualmente en el entorno. No asuma que la versión coincide con la aplicación principal de GitLab. Segundo, aplique el parche correspondiente de inmediato utilizando los procedimientos de Docker o Helm proporcionados por GitLab. Tercero, considere rotar las claves de firma JWT si la pasarela estuvo expuesta a usuarios internos no confiables antes de que se aplicara el parche.

Finalmente, audite la lista de usuarios que tienen permiso para configurar flujos personalizados en Duo Agent Platform. Si un usuario no tiene una razón crítica para modificar estas configuraciones, elimine su acceso. Reducir el número de personas que pueden alcanzar la vulnerabilidad es tan importante como corregir el código en sí. La seguridad es un proceso continuo de refinamiento, no una actualización única.

Fuentes

• GitLab Security Advisory (CVE-2026-90970)
• CISA Known Exploited Vulnerabilities Catalog (Assessment Phase)
• CWE-1336: Improper Neutralization of Directives in Web Page Templates
• NIST Guide to Enterprise Patch Management Strategies

Descargo de responsabilidad: Este artículo es solo para fines informativos y educativos. No reemplaza una auditoría de ciberseguridad profesional o un servicio de respuesta a incidentes. Consulte siempre la documentación oficial del proveedor antes de realizar actualizaciones del sistema.