El AI Gateway de GitLab permitió que una configuración de flujo manipulada se escapara de su sandbox de prompts.

El 2 de octubre de 2026, GitLab publicó una versión de parche crítico para su AI Gateway —el middleware que transporta las solicitudes entre una instancia de GitLab y los modelos de lenguaje que llaman sus funciones Duo—, y lo denominó CVE-2026-90970 y le asignó una calificación de 9,9 sobre 10. La falla, en palabras del propio GitLab, podría haber permitido que «un usuario autenticado con acceso a Duo Agent Platform escapara del sandbox de plantillas de prompt mediante una configuración de flujo especialmente manipulada, lo que habría dado lugar a la ejecución arbitraria de comandos en el AI Gateway». Solo las organizaciones que ejecutaban un AI Gateway autoalojado tenían que actuar: GitLab ya había corregido los gateways que opera para GitLab.com, GitLab Dedicated y los clientes autogestionados que utilizan un gateway alojado por GitLab, y así lo indicó en el aviso. El aviso de GitLab no afirma que la vulnerabilidad haya sido explotada alguna vez, y la evaluación que la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. adjuntó al registro de la CVE ese mismo día califica la explotación como «ninguna». El crédito por el hallazgo se atribuyó al investigador de HackerOne conocido como invisiblemeerkat. El aviso de GitLab, el registro del NVD y la cobertura informativa que le siguió coinciden entre sí en qué consistía la falla y qué versiones la incluían; también coinciden en lo que no se sabe, es decir, si alguien llegó a utilizarla. Este registro se suma a las demás vulnerabilidades documentadas de la infraestructura de agentes en el archivo de incidentes de IA, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza e indicador de disputa.

Lo que realmente dice el aviso y lo que omite

El aviso es breve. Publicado en el sitio de documentación de GitLab con el título «Lanzamiento de parche crítico de GitLab AI Gateway: 19.2.4, 19.3.2 y 19.4.1», enumera una única corrección de seguridad, titulada «Problema de neutralización incorrecta en la plantilla de prompt de flujo personalizado afecta a AI Gateway» y marcada como Crítica. Indica que el vector CVSS 3.1 es AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — accesible por red, baja complejidad de ataque, se requieren privilegios bajos, sin interacción del usuario, alcance cambiado y alto impacto en confidencialidad, integridad y disponibilidad. Merece la pena leer ese vector porque es preciso respecto al atacante: privilegios bajos, pero privilegios al fin y al cabo. El aviso dice «un usuario autenticado con acceso a Duo Agent Platform» y se detiene ahí. No nombra el rol, el permiso ni las condiciones a las que se refiere su propia frase «en determinadas condiciones».

No publica una prueba de concepto, no describe la configuración de flujo manipulada y no ofrece una solución alternativa para las puertas de enlace que no se puedan actualizar de inmediato. The Hacker News, en su informe del 2 de octubre, señala las mismas ausencias y añade una que importa operativamente: el aviso no ofrece ninguna forma de comprobar si se atacó una puerta de enlace antes de que se le aplicara el parche. Security Affairs, al escribir al día siguiente, registra las mismas lagunas.

La entrada de enumeración de debilidades comunes asociada al CVE es CWE-1336, neutralización incorrecta de elementos especiales utilizados en un motor de plantillas. El aviso de GitLab nunca usa la palabra Jinja. La propia documentación del repositorio de AI Gateway sí lo hace: su documento de registro de prompts describe archivos de configuración de prompts que «admiten expresiones Jinja para múltiples roles, como usuario y sistema», y describe una clase Prompt que «usa Jinja para interpolar las plantillas de prompt con los argumentos de entrada». La brecha que describe el CVE es aquella por la que esa clase de motor es famosa: texto proporcionado por el usuario que llega a una plantilla que se evalúa en lugar de imprimirse.

Por qué un comando en este host en particular vale 9,9

El AI Gateway no es un sidecar. Según la documentación autoalojada de GitLab, recibe solicitudes de GitLab, ensambla los prompts y se comunica con el backend del modelo —un servidor vLLM, A​mazon Bedrock, Azure O​penAI o un proveedor externo—, y en una implementación totalmente autoalojada es el componente que mantiene los prompts y las respuestas dentro de la propia red de la organización. La guía de instalación del AI Gateway de GitLab también indica a los administradores que generen un par de claves de firma y pasen las dos mitades al servicio como variables de entorno, como AIGW_SELF_SIGNED_JWT__SIGNING_KEY y AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (con equivalentes de Duo Workflow). Security Affairs explicita la consecuencia: la ejecución de comandos en el gateway coloca a un atacante en un host que contiene material de firma JWT y que se encuentra en la ruta entre la instancia de GitLab y la infraestructura del modelo.

Esa es la diferencia entre un escape de sandbox en un juguete y uno en producción. El escape no necesita llegar a un modelo; necesita llegar al proceso que guarda las claves con las que se firman las llamadas al modelo.

La documentación del producto de GitLab, por separado del aviso, indica que crear o editar un flujo personalizado requiere el rol de Maintainer u Owner en el proyecto de gestión, y que ejecutar uno requiere Developer o superior. El aviso no confirma esa correspondencia, y The Hacker News señala que no se nombra ningún rol más allá de "acceso a Duo Agent Platform". Un lector que estime su propia exposición debería tratar la documentación como el modelo de permisos del producto y el silencio del aviso como exactamente eso: silencio, no una contradicción.

Establecido, y no establecido

Los propios campos del registro son coherentes con todo lo anterior y no añaden nada que no esté en el aviso. Lo que sigue es el desglose que un lector no puede obtener de un resumen de una sola línea.

• Establecido: una vulnerabilidad de gravedad crítica en GitLab AI Gateway, divulgada el 2 de octubre de 2026, CVSS 9.9, CWE-1336, a la que puede acceder un usuario autenticado de Duo Agent Platform mediante una configuración de flujo manipulada, lo que da como resultado la ejecución de comandos en el host de la puerta de enlace.

• Establecido: el rango afectado — todas las versiones de AI Gateway desde la 18.1.6 anterior a la 19.2.4, la 19.3 anterior a la 19.3.2 y la 19.4 anterior a la 19.4.1 — y las versiones corregidas, 19.2.4, 19.3.2 y 19.4.1.

• Establecido: Las pasarelas alojadas por GitLab se parchearon antes de la publicación y sus clientes no necesitan tomar ninguna medida; los operadores de instancias autohospedadas fueron contactados directamente antes de la publicación de la versión, lo que GitLab indica en el propio aviso.

• Establecido: el crédito del informante, a invisiblemeerkat, y la ausencia de cualquier declaración de explotación en la naturaleza.

• No establecido:si alguien lo explotó. Una evaluación SSVC de CISA fechada el 2 de octubre de 2026 y visible en el registro del NVD indica la explotación como «ninguna», automatizable como «no» y el impacto técnico como «total»; el catálogo Known Exploited Vulnerabilities de CISA no incluía CVE-2026-90970 en su revisión del 20 de octubre de 2026, que consulté directamente. El modelo EPSS de FIRST situó la probabilidad de explotación en los próximos 30 días en 0,94 por ciento el 21 de octubre de 2026 — baja, y no cero.

• No establecido:cuántas puertas de enlace autoalojadas existen, cuántas estuvieron expuestas o si alguna fue atacada antes de que se aplicara el parche. Ninguna fuente de este registro proporciona un recuento, y el aviso de GitLab no ofrece ningún método de detección.

El rango afectado y las versiones sin corrección indicada

La aritmética de las versiones es menos ordenada de lo que sugieren las tres versiones corregidas. El intervalo afectado comienza en la 18.1.6, y no se ha publicado ninguna versión corregida en ninguna rama inferior a la 19.2.4. Por lo tanto, todos los gateway desde la 18.1.6 hasta la serie 19.1 quedan dentro del intervalo afectado indicado, sin que se nombre ninguna versión parcheada para ellos. The Hacker News señala la misma consecuencia y las preguntas que se derivan: la documentación de instalación de GitLab indica a los administradores que ejecuten la imagen del gateway cuya versión coincida con su versión menor de GitLab, y el aviso no indica si un gateway 19.2.4 funciona con GitLab 19.1 o versiones anteriores, ni si se planean correcciones para las ramas más antiguas. La política de versiones compatibles de GitLab, como señala The Hacker News, actualmente enumera 19.4, 19.3 y 19.2 —las mismas tres ramas que recibieron correcciones.

La remediación consiste en sustituir el contenedor, no en aplicar un parche: la puerta de enlace se distribuye como su propia imagen de Docker o chart de Helm. La guía de instalación de GitLab describe cómo detener y eliminar el contenedor en ejecución, descargar la nueva imagen con una etiqueta self-hosted-vX.Y.Z-ee y volver a iniciarlo con las variables de entorno intactas; en las implementaciones con Helm, la etiqueta se define en el campo image del chart. Ni el aviso ni la guía de instalación ofrecen una firma o un indicador que permita distinguir una puerta de enlace atacada de una limpia.

La misma clase de bug, ocho meses antes

No es la primera vez que GitLab publica un 9,9 por inyección de plantillas en AI Gateway. El 6 de febrero de 2026 lanzó AI Gateway 18.6.2, 18.7.1 y 18.8.1 para CVE-2026-1868, descrita en ese aviso como un "problema de expansión de plantillas insegura" en el que el componente Duo Workflow Service era "vulnerable a la expansión insegura de plantillas de datos proporcionados por el usuario mediante definiciones de Duo Agent Platform Flow manipuladas", explotable para denegación de servicio o ejecución de código en la puerta de enlace. El vector CVSS es idéntico al de octubre, carácter por carácter, y también lo es el CWE. El informante fue diferente: esa fue encontrada internamente, por el miembro del equipo de GitLab Joern Schneeweisz.

El aviso de octubre no menciona el de febrero, y The Hacker News lo dice explícitamente. Si ambos comparten una causa raíz, una corrección que no se mantuvo, o simplemente un lenguaje y un modelo de amenazas, no es algo que responda ninguno de los dos documentos públicos. Lo que consta en el registro es que un motor de plantillas en un componente de middleware de IA ha producido ahora dos avisos críticos de ejecución de comandos con la misma puntuación en el mismo año, y que el segundo requirió que un investigador externo lo encontrara.

Qué ha cambiado y qué les queda por decidir a los operadores

El cambio concreto son tres etiquetas de imagen y una ronda de contacto directo. GitLab dice que se puso en contacto con los clientes de la puerta de enlace autoalojada antes de publicar, y el aviso se publicó junto con las imágenes corregidas el mismo día. Para todos los demás —GitLab.com, GitLab Dedicated e instancias autogestionadas que apuntan a una puerta de enlace alojada por GitLab—, la corrección ya se había aplicado del lado del servidor y, según GitLab, no se requería nada.

Para quien opera una instalación autoalojada, la decisión es más limitada y menos cómoda que en un ciclo de parches normal. No hay solución alternativa para una gateway que no pueda actualizarse de inmediato. No existe un método publicado para determinar si el host ya estaba comprometido, lo que significa que la única opción retrospectiva es la habitual: tratar el contenedor como un sistema cuya integridad no está demostrada y buscar indicios de ejecución fuera de su comportamiento normal. Y para las gateways en 18.x o 19.1, el aviso no nombra ninguna versión de destino —una omisión que The Hacker News señala y que el comunicado de GitLab no aborda.

La clasificación propia del archivo es deliberadamente más estrecha que la del proveedor. Registra esta entrada como una vulnerabilidad, con confianza A y las fuentes de acuerdo, sin disputa, sin daños reales registrados y con un campo de gravedad de «high» frente al «critical» de GitLab y NVD. Son respuestas a preguntas distintas: la puntuación describe lo que permitiría el fallo, y la calificación del archivo describe lo que se sabe que ocurrió. Según el registro público, no ocurrió nada —ninguna explotación, ninguna víctima, ningún informe de incidente. El valor de la entrada es que documenta, con un número CVE y una versión corregida, exactamente cómo una plantilla de prompt se convirtió en una línea de comandos en el middleware del que dependen las funciones de IA empresarial.