GitLab parchea CVE-2026-90970: RCE crítica de 9.9 en el AI Gateway que escapa del sandbox de prompts

GitLab publicó el viernes 2 de octubre de 2026 una vulnerabilidad crítica en su AI Gateway, el servicio que conecta las instancias de GitLab con los modelos de lenguaje que alimentan funciones de Duo Agent Platform. Catalogada como CVE-2026-90970 con una puntuación CVSS de 9.9 sobre 10, la vulnerabilidad permite escapar del aislamiento de plantillas de prompts mediante una configuración de flujo manipulada y, desde ahí, ejecutar comandos arbitrarios sobre el propio gateway.

El aviso no nombra un rol específico de usuario, pero deja claro que cualquier persona autenticada con acceso a Duo Agent Platform puede explotarla. La Autoridad de Ciberseguridad e Infraestructura de Estados Unidos (CISA) añadió su evaluación al registro del CVE el mismo 2 de octubre y clasificó la explotación como “none”, es decir, sin constancia de uso en ataques reales ni de prueba de concepto pública por el momento. El reporte se atribuye al usuario de HackerOne invisiblemeerkat.

<h2>Qué es el AI Gateway y por qué importa</h2>

El AI Gateway es el componente que GitLab introdujo para desacoplar las llamadas a modelos de IA del núcleo del repositorio. Por un lado habla con el GitLab principal y por el sistema de desarrollo se comunica con los proveedores de modelos que la organización haya contratado. En su variante autoalojada, GitLab Duo Self-Hosted, el gateway corre como una imagen Docker o chart de Helm independiente dentro de la infraestructura del cliente, lo que en teoría mantiene los prompts, los secretos y el código dentro del perímetro corporativo.

Esa autonomía, sin embargo, convierte al gateway en un objetivo de alto valor: custodia claves de firma para JSON Web Tokens (JWT) según la propia guía de instalación de GitLab, mantiene conexiones privilegiadas a la instancia principal de GitLab y, además, tiene credenciales hacia los proveedores de modelos. Un RCE sobre el gateway equivale a un punto de pivote ideal para moverse lateralmente hacia el repositorio y para exfiltrar prompts, código fuente y secretos.

<h2>El fallo técnico: CWE-1336 en una plantilla de prompt</h2>

El aviso oficial es deliberadamente parco, pero hay tres datos que permiten reconstruir el problema. El primero es el identificador de debilidad: CWE-1336, es decir, neutralización incorrecta de elementos especiales usados en una plantilla. El segundo es la ubicación: el fallo vive en la plantilla de prompt de un flujo custom creado sobre Duo Agent Platform. El tercero es el efecto: un usuario autenticado puede “escapar del sandbox de la plantilla de prompts mediante una configuración de flujo especialmente manipulada”, lo que se traduce en ejecución arbitraria de comandos sobre el gateway.

En términos prácticos esto significa que la entrada que un usuario aporta al definir un flujo custom no se sanea correctamente antes de componerse con la plantilla que finalmente se envía al modelo. La configuración manipulada rompe la frontera entre la entrada del usuario y el contexto que el gateway trata como código interno, y a partir de ahí el atacante puede invocar comandos del sistema operativo fuera del entorno aislado. La clase de bug es la misma que la del CVE-2026-1868, también de 9.9, que GitLab parcheó en febrero de 2026 y que también afectaba al AI Gateway por la vía de una definición de flujo maliciosa.

<h2>Quién está afectado y quién no</h2>

La vulnerabilidad solo impacta a despliegues con AI Gateway autoalojado. Los clientes que usan GitLab.com, GitLab Dedicated o instancias self-managed que consumen un gateway operado por GitLab ya están protegidos y no necesitan hacer nada. La matriz de versiones afectadas y corregidas lo deja meridianamente claro:

<ul><li>AI Gateway 18.1.6 o posterior, hasta antes de 19.2.4 → fija en 19.2.4.</li><li>AI Gateway 19.3, antes de 19.3.2 → fija en 19.3.2.</li><li>AI Gateway 19.4, antes de 19.4.1 → fija en 19.4.1.</li></ul>

No hay versión corregida por debajo de 19.2.4, lo que deja toda la línea 18.1.6 a 19.1 dentro del rango afectado. La política de mantenimiento de GitLab solo da soporte de seguridad a las ramas 19.2, 19.3 y 19.4, así que no se esperan parches para líneas más antiguas. El aviso no detalla si un gateway 19.2.4 es compatible con una instancia principal de GitLab anterior a 19.2, un punto a verificar en cada despliegue antes de actualizar.

<h2>Cómo actualizar y qué se puede hacer mientras tanto</h2>

El AI Gateway se distribuye y actualiza de forma independiente a la instancia principal. En Docker hay que detener y eliminar el contenedor en marcha y, a continuación, descargar y arrancar la nueva, por ejemplo <code>self-hosted-v19.4.1-ee</code>. En despliegues con Helm basta con fijar el valor de la etiqueta de imagen en el chart y redeployar. GitLab insiste en la actualización inmediata y, según el aviso, contactó de forma dirigida a clientes con gateway autoalojado antes de publicar la advisory.

El aviso no lista workaround alguno para entornos que aún no puedan actualizar, y tampoco aporta una forma de saber si un gateway fue explotado antes del fix. En la práctica esto significa que cualquier despliegue que haya tenido AI Gateway expuesto entre la introducción del código vulnerable y el 2 de octubre de 2026 debe asumir que la superficie estuvo disponible, y conviene revisar logs del gateway, procesos hijos anómalos y conexiones salientes hacia destinos no habituales. La política de mantenimiento de la propia compañía deja en el aire a quienes ejecuten líneas previas a 19.2, para los que la única salida es planificar la migración.

<h2>El patrón: el sandbox de prompts como nueva superficie</h2>

Este es el segundo 9.9 que GitLab parcheca en el AI Gateway en menos de un año y los dos comparten firma. CVE-2026-1868 en febrero y CVE-2026-90970 ahora son debilidades de tipo CWE-1336 en la composición de plantillas que mezclan código y datos, una clase de error que en la era de los servidores MCP y los agentes agénticos se va a repetir. Los gateways de IA comparten tres propiedades que los hacen especialmente jugosos: hablan lenguajes cercanos al natural, ensamblan prompts con cadenas que a menudo incluyen variables controladas por el usuario, y se ejecutan con privilegios altos porque necesitan mover datos sensibles.

Hay además una segunda lectura. El informe Microsoft Digital Defense Report 2026 publicado dos días antes, el 1 de octubre, situaba la mediana de tiempo entre la divulgación de un CVE y un arma utilizable por debajo de 24 horas. Aunque CISA marca CVE-2026-90970 como “sin explotación conocida” a día de hoy, la categoría de bug es de las que pasan rápido de “prueba de concepto” a “explotada en gran escala” en cuanto alguien con tiempo la pule. Equipos que autoalojen AI Gateway deberían tratarlo como crítico y no como mera actualización de mantenimiento.

<h2>Qué hacer esta semana</h2>

Si tu organización autoaloja el AI Gateway de GitLab, el orden de operaciones es directo. Primero, identificar la versión exacta del gateway en uso y cruzarla con la matriz anterior. Segundo, planificar la actualización a 19.2.4, 19.3.2 o 19.4.1 según rama, validando compatibilidad con la instancia principal de GitLab en un entorno de pruebas antes de promover. Tercero, revisar los logs del gateway desde la introducción del código vulnerable en busca de configuraciones de flujo anómalas o procesos hijos no esperados, asumiendo que la superficie estuvo disponible. Cuarto, recordar que la vulnerabilidad requiere autenticación con acceso a Duo Agent Platform, así que conviene revisar quién tiene ese permiso y endurecerlo al mínimo imprescindible.

Y, como siempre que un proveedor publica un 9.9, tomar nota: la cadena de suministro de IA empieza a tener su propio historial de CVEs críticos, y la cadencia entre el de febrero y este octubre apunta a que el AI Gateway de GitLab, y los equivalentes de otras suites DevSecOps, se van a convertir en un frente habitual de disclosure durante los próximos meses.