GitLab corrige CVE-2026-90970 crítico en AI Gateway; parches para self-hosted

GitLab ha publicado un aviso de seguridad que describe una vulnerabilidad crítica en su servicio AI Gateway que, en determinadas condiciones, permitía a un usuario autenticado con acceso a la plataforma Duo Agent escapar del “sandbox” de plantillas de prompts y ejecutar comandos arbitrarios en el propio gateway. El fallo se ha registrado como CVE-2026-90970, recibió una puntuación CVSS de 9.9/10 y GitLab publicó la corrección el 2 de octubre. Las versiones que contienen la solución son 19.2.4, 19.3.2 y 19.4.1 del componente AI Gateway.

Hechos confirmados: GitLab describe el problema como una debilidad en la plantilla de prompts de un “custom flow” —flujos personalizados creados en la Duo Agent Platform para automatizar tareas— que podía permitir la “escape” del entorno seguro y derivar en ejecución de comandos en la máquina que ejecuta el gateway. GitLab opera gateways administrados para clientes en GitLab.com y GitLab Dedicated y afirma haber ya mitigado el problema en sus gateways gestionados; por tanto, solo las organizaciones que alojan su propio AI Gateway (self-hosted) deben aplicar el parche. El aviso identifica las versiones fijas arriba indicadas y no lista ninguna mitigación alternativa ni una forma incorporada para comprobar si un gateway fue atacado antes de actualizarlo.

Contexto técnico y alcance: el AI Gateway es el componente que conecta una instancia de GitLab con modelos de IA externos y, en despliegues self-hosted, se instala como una imagen Docker o mediante Helm. Ese gateway almacena claves de firma para JSON Web Tokens (JWT) y mantiene conexiones con el GitLab interno y los proveedores de modelos —por lo tanto, la afectación potencial no es solo al contenedor del gateway, sino también a credenciales que facilitan autenticación y autorización en el entorno. GitLab califica el problema como de la misma clase que una vulnerabilidad previa en febrero (CVE-2026-1868) —ambas relacionadas con debilidades en el motor de plantillas, clase CWE-1336—, lo que indica un patrón en cómo las plantillas de flujo pueden ser manipuladas para romper límites de ejecución.

Qué sabemos y qué no: confirmado está que un usuario autenticado con acceso a Duo Agent Platform era la vía de ataque descrita; sin embargo, el aviso no detalla los requisitos exactos (por ejemplo, qué rol de usuario concreto era necesario o qué condiciones de configuración del gateway se explotaban). Tampoco se ha publicado una prueba de concepto pública, y la entrada del CVE incluye una valoración de la CISA que enumera la explotación como “none” en su campo de explotación conocida, lo que sugiere que no hay confirmación pública de ataques en el panorama general. Aun así, la naturaleza de la vulnerabilidad —ejecución de comandos en un componente que guarda claves sensibles— convierte el riesgo en serio y con consecuencias potencialmente graves si fuera explotada en entornos productivos.

Consecuencias reales y riesgo para organizaciones: si un atacante consigue ejecutar código en un gateway comprometido, puede intentar exfiltrar o rotar las claves JWT, interceptar o modificar peticiones y respuestas de IA, moverse lateralmente hacia la instancia de GitLab o los proveedores de modelos, e incluso desplegar cargas maliciosas. En entornos donde la política del cliente obliga a que los datos de entrada y salida de IA permanezcan dentro del perímetro (self-hosted gateway), la exposición del gateway comprometería esa garantía y pondría en riesgo datos sensibles. Por tratarse de un componente que suele tener permisos de red amplios para comunicarse con GitLab y con APIs externas, la escalada de impacto es plausible.

Recomendaciones concretas e inmediatas (verificables y ejecutables): 1) Actualizar inmediatamente cualquier AI Gateway self-hosted a una de las versiones corregidas: 19.2.4, 19.3.2 o 19.4.1 según corresponda a la línea que use su instalación. Para despliegues Docker, parar y eliminar el contenedor actual, hacer docker pull de la nueva etiqueta y ejecutar el contenedor con la misma configuración; GitLab usa etiquetas con nombres como por ejemplo self-hosted-v19.4.1-ee. Para despliegues con Helm, ajuste la imagen en el chart (image.tag) y aplique helm upgrade para desplegar la nueva etiqueta. 2) Rotar claves y credenciales sensibles: si el gateway guarda claves JWT o credenciales de proveedores de modelos, prepare un plan de rotación inmediata de esas claves tras la actualización. Aunque no exista confirmación de explotación, la rotación mitiga el riesgo de compromiso previo. 3) Revisar y restringir acceso: audite quién tiene permisos en Duo Agent Platform y aplique el principio de menor privilegio; considere deshabilitar la creación de flows por usuarios no imprescindibles hasta completar la actualización. 4) Monitoreo y búsqueda de indicadores: revise logs del gateway y del host para detectar ejecuciones anómalas, procesos desconocidos, reinicios súbitos o cambios en configuraciones de flows; si dispone de snapshots o copias de seguridad, compárelas para detectar modificaciones. 5) Entorno de prueba: primero aplique el parche en entornos de staging y valide compatibilidad con su versión de GitLab antes de desplegar en producción, porque la guía de instalación recomienda usar la imagen de gateway que corresponde a la versión menor de GitLab y el aviso no aclara compatibilidades inversas entre versiones.

Acciones de mitigación cuando no es posible actualizar de inmediato: si por restricciones operativas no puede aplicar el parche de inmediato, reduzca el riesgo —temporalmente— aislando la red del gateway para limitar su capacidad de comunicarse fuera del perímetro, aplique controles de firewall para restringir accesos entrantes y salientes, y deshabilite la funcionalidad de flows o la capacidad de usuarios de cargar configuraciones de flow hasta que la actualización sea posible. Estas medidas son paliativas y no sustituyen la actualización del software.

Qué comunicar a los equipos y próximos pasos: informe a los equipos de seguridad e infraestructura, documente la versión del gateway y la fecha/hora de la actualización, conserve logs antes de rotar claves y notifique a los departamentos de cumplimiento si el gateway gestiona datos regulados. GitLab agradeció al investigador reportante (usuario “invisiblemeerkat” en HackerOne) y ya resolvió el problema en los gateways que administra para clientes; sin embargo, la responsabilidad de actualización recae en los operadores de gateways self-hosted.

Fuentes y lectura adicional: el aviso de seguridad de GitLab y documentación sobre seguridad de sus servicios están disponibles en la web de GitLab (https://about.gitlab.com/security/). La entrada del CVE puede consultarse en el NVD para detalles estructurados y enlaces asociados (https://nvd.nist.gov/vuln/detail/CVE-2026-90970), y para contexto técnico sobre la clase de debilidad referida puede consultarse la definición CWE-1336 en MITRE (https://cwe.mitre.org/data/definitions/1336.html).

Resumen: si usted aloja un AI Gateway propio, actualice ya. Si su GitLab está alojado por GitLab (GitLab.com, GitLab Dedicated o usa un gateway gestionado), GitLab indica que sus gateways ya fueron parcheados y no es necesaria acción por su parte. Donde no sea posible actualizar de inmediato, aísle, restrinja accesos y prepare rotaciones de claves; documente todas las acciones y mantenga una vigilancia reforzada hasta terminar la contención y verificación.