La vulnerabilidad de GitLab AI Gateway rompe el sandbox y permite la ejecución de comandos
GitLab ha corregido una vulnerabilidad de GitLab AI Gateway con una puntuación de 9,9 sobre 10 después de que investigadores descubrieran una vía para la ejecución arbitraria de comandos. El fallo afecta a los gateways autoalojados y requiere un usuario autenticado con acceso a GitLab Duo Agent Platform. Un flujo personalizado especialmente diseñado puede escapar del sandbox de plantillas de prompts y ejecutar comandos con los privilegios del proceso del gateway.
El incidente tiene un alcance más limitado que el de una vulnerabilidad explotable de forma remota que afectara a todas las implementaciones de GitLab. La empresa corrigió los gateways alojados por GitLab, y los clientes que utilizan esos servicios no necesitan actualizar el gateway por su cuenta. Las organizaciones que operan un AI Gateway autoalojado tienen la responsabilidad inmediata.
Esa distinción genera la tensión central. El autoalojamiento ofrece a una organización mayor control sobre el procesamiento de IA, la infraestructura y las rutas de datos. También transfiere al cliente las tareas de aplicación de parches, supervisión y contención. En este caso, el componente situado dentro del entorno de confianza se convirtió en un objetivo para la ejecución de comandos.
La vulnerabilidad se rastrea como CVE-2026-90970. GitLab lanzó las versiones 19.2.4, 19.3.2 y 19.4.1 de AI Gateway el 2 de octubre de 2026. La empresa instó a los operadores afectados a actualizar de inmediato, pero su aviso público no identificó una solución alternativa ni proporcionó orientación detallada para detectar compromisos.
La vulnerabilidad de GitLab AI Gateway requiere una actualización inmediata
El hecho urgente es simple: los gateways autoalojados afectados necesitan una versión corregida de AI Gateway, no solo una aplicación GitLab actualizada.
El aviso de parche crítico de GitLab identifica tres versiones corregidas: 19.2.4, 19.3.2 y 19.4.1. El número de versión pertinente corresponde al componente AI Gateway. No debe confundirse con la versión de una instancia de GitLab conectada.
El rango afectado comienza con AI Gateway 18.1.6. Incluye las versiones anteriores a 19.2.4, la versión 19.3 anterior a 19.3.2 y la versión 19.4 anterior a 19.4.1. Las organizaciones que ejecuten una rama compatible más antigua deben seleccionar la versión corregida adecuada.
La redacción también importa para las instalaciones en las líneas 18.x y 19.1. GitLab no incluyó una versión corregida del gateway anterior a 19.2.4 en el aviso de octubre. Los operadores de esas líneas no deben asumir que permanecer en una rama más antigua proporciona protección.
Un AI Gateway autoalojado se ejecuta como un servicio independiente, normalmente mediante un contenedor o una implementación de Helm. Actualizar la aplicación principal de GitLab no demuestra automáticamente que se haya sustituido la imagen del gateway. Los administradores deben inspeccionar la implementación del gateway y confirmar la etiqueta de imagen en ejecución.
GitLab indicó que contactó a los clientes de gateways autoalojados antes de publicar el aviso. También afirmó que ya había desplegado una corrección en los gateways alojados por GitLab. Eso protege GitLab.com, GitLab Dedicated y las instancias autogestionadas conectadas a un gateway alojado por GitLab.
Este alcance convierte la identificación de activos en el primer desafío operativo. Un equipo de seguridad podría saber que su organización utiliza GitLab Duo sin saber qué modelo de gateway lo respalda. El servicio puede ser operado por GitLab o desplegado dentro del entorno del cliente.
Los equipos deben verificar esa distinción mediante registros de implementación, inventarios de contenedores, versiones de Helm y la configuración de GitLab Duo. Deben evitar inferir la propiedad del gateway únicamente a partir del nombre del producto GitLab. Una instancia de GitLab autogestionada aún puede usar un gateway alojado por GitLab.
El registro CVE asigna a la vulnerabilidad los impactos máximos en confidencialidad, integridad y disponibilidad dentro de su vector CVSS 3.1. La puntuación es 9,9 en lugar de 10 porque la explotación requiere privilegios bajos. No requiere interacción del usuario y el servicio vulnerable es accesible a través de una red.
Los privilegios bajos no significan acceso anónimo. GitLab afirma que un atacante debe estar autenticado y tener acceso a Duo Agent Platform. Ese requisito reduce la población inicial de atacantes, pero incluye cuentas comprometidas y posibles actores internos maliciosos.
El fallo cruza una frontera de seguridad después de ese acceso inicial. Un usuario autorizado para trabajar con flujos de IA no debería heredar permiso para ejecutar comandos del sistema operativo en el gateway. La vulnerabilidad convierte el acceso a nivel de aplicación en control sobre un entorno de ejecución más sensible.
Los operadores deben tratar la actualización como un cambio independiente con pruebas independientes. Un ticket de cambio completado para GitLab no establece que AI Gateway sea seguro. La prueba correcta es la versión del gateway en ejecución y un despliegue verificado en cada réplica.
Esa verificación debe incluir entornos de desarrollo, pruebas, recuperación ante desastres y entornos temporalmente reducidos. Las instancias de gateway olvidadas siguen siendo importantes si conservan conectividad de red o credenciales. Una interfaz inactiva no garantiza que el servicio sea inaccesible.
Un flujo personalizado convirtió los datos de plantilla en comportamiento ejecutable
El fallo central no fue que un modelo de IA escribiera un comando peligroso. Fue que una frontera de plantilla permitió que datos diseñados maliciosamente alcanzaran un comportamiento ejecutable de la aplicación.
GitLab describe el problema como una neutralización inadecuada en una plantilla de prompt de flujo personalizado. Un flujo personalizado es un flujo de trabajo de IA configurable y de varios pasos dentro de Duo Agent Platform. Puede combinar prompts, componentes, decisiones de enrutamiento y herramientas en una definición YAML.
La documentación sobre flujos personalizados de la empresa muestra por qué estas definiciones son más que texto de prompts convencional. Los flujos pueden crearse, probarse, publicarse, habilitarse para proyectos y activarse mediante la actividad de GitLab. Funcionan como configuración de la aplicación en torno a un agente.
La ruta vulnerable implicaba un sandbox de plantillas de prompts. Un sandbox es un entorno de ejecución restringido destinado a impedir que una plantilla alcance atributos o funciones inseguras. CVE-2026-90970 permitió que una configuración de flujo manipulada escapara de esas restricciones.
Un ticket público de divulgación de GitLab atribuye el problema al acceso inseguro a métodos durante el renderizado de plantillas Jinja2. Jinja2 es un motor de plantillas de Python que combina texto con variables y expresiones.
Según el ticket, el historial de conversación contenía un objeto HumanMessage de LangChain. La plantilla podía llamar a un método público de deserialización sobre ese objeto. Una carga serializada insegura provocaba entonces que Python ejecutara comandos del sistema operativo durante la deserialización.
La deserialización convierte datos almacenados o transmitidos de nuevo en un objeto de programa. Se vuelve peligrosa cuando el formato seleccionado puede invocar código mientras reconstruye ese objeto. Los datos pickle de Python son un ejemplo bien conocido, porque cargar contenido pickle no confiable es inseguro.
La prueba de concepto reportada utilizó un flujo de dos pasos. La primera interacción con el modelo llenaba el historial de conversación. Una evaluación posterior de la plantilla accedía a ese objeto de historial y activaba la peligrosa ruta de deserialización.
Esta secuencia diferencia el problema de un error básico de inyección de shell. El valor malicioso no necesitaba aparecer como un parámetro de comando directo pasado a un shell. En su lugar, varias funciones significativas por separado formaron la cadena de ejecución.
El flujo aceptaba contenido de prompts configurable. El motor de plantillas recibía objetos de aplicación. Uno de los objetos exponía un método de deserialización. El formato de serialización aceptado podía invocar código. En conjunto, esas condiciones derrotaron el sandbox previsto.
El propio modelo no era la frontera de seguridad de confianza. Ayudó a hacer avanzar el flujo entre estados, pero el comando se ejecutó mediante un comportamiento determinista de la aplicación. Filtrar únicamente la salida del modelo no resolvería la relación vulnerable entre el objeto y la plantilla.
Esta distinción importa cuando las organizaciones clasifican los fallos de seguridad de IA. La inyección de prompts describe intentos de manipular un modelo mediante instrucciones. CVE-2026-90970 es una vulnerabilidad de software en el sistema que rodea al modelo, aunque una plantilla de prompt proporcione el punto de entrada.
Por tanto, las prácticas tradicionales de seguridad de aplicaciones siguen siendo esenciales. Las entradas de las plantillas necesitan una validación estricta, los objetos expuestos necesitan interfaces mínimas y los formatos de deserialización peligrosos no deben procesar datos controlados por atacantes. Los sandboxes también deben probarse con los objetos exactos disponibles dentro de ellos.
Los comandos reportados se ejecutaron con los privilegios del proceso Duo Workflow Service. Eso limita la autoridad inmediata del sistema operativo a los permisos de la cuenta de servicio. Sin embargo, la ejecución a nivel de servicio sigue siendo grave porque el gateway maneja conexiones sensibles y se encuentra dentro de una infraestructura de confianza.
El impacto práctico depende de la arquitectura de implementación. Un contenedor con privilegios mínimos y redes restringidas presenta menos vías posteriores que un servicio ampliamente conectado. Ninguna configuración elimina la necesidad de aplicar el parche, porque un atacante seguiría obteniendo ejecución de código no intencionada.
Este mecanismo explica la gravedad cercana al máximo. El atacante comienza con una identidad autenticada con capacidades de Duo, pero la ejecución resultante cruza al contexto de seguridad del gateway. Ese cambio de alcance es fundamental para la puntuación de 9,9.
El autoalojamiento desplaza el control y la responsabilidad de seguridad de forma conjunta
El incidente expone la contrapartida de la infraestructura de IA autoalojada: mantener el procesamiento cerca también sitúa el gateway dentro de la frontera de confianza operativa del cliente.
GitLab describe AI Gateway como un servicio independiente que conecta las funciones de GitLab Duo con modelos de IA. Los clientes pueden utilizar el gateway administrado de GitLab u operar su propio gateway con GitLab Duo Self-Hosted.
Las organizaciones suelen elegir el autoalojamiento para controlar el movimiento de datos, el acceso a modelos, las rutas de red y la política de infraestructura. Estas ventajas pueden ser importantes en entornos regulados o implementaciones con controles internos estrictos. También crean otro servicio de producción que los clientes deben inventariar y mantener.
La vulnerabilidad de GitLab AI Gateway convierte ese detalle operativo en el principal problema de seguridad. GitLab pudo desplegar una corrección directamente en los gateways que administra. Los clientes autoalojados deben programar, ejecutar y verificar sus propias actualizaciones.
Este patrón es conocido en bases de datos, servicios de identidad y runners de CI. La diferencia es que los gateways de IA unen sistemas que antes estaban más claramente separados. Se sitúan entre usuarios, repositorios de código fuente, flujos de trabajo de agentes, proveedores de modelos y, en ocasiones, herramientas de ejecución.
Por tanto, un gateway comprometido merece más atención que una interfaz de chatbot aislada. Según la configuración, puede encontrar contenido de prompts, estado de flujos de trabajo, credenciales de servicio, conexiones de proveedores o metadatos sobre actividad interna de desarrollo.
Eso no establece que CVE-2026-90970 expusiera todos los secretos conectados. El aviso de GitLab no informa de robo de datos confirmado ni de una ruta completa de explotación posterior. La conclusión correcta es que la ejecución arbitraria de comandos crea una vía creíble hacia un acceso adicional.
Los equipos deben evaluar el gateway como un servicio de integración privilegiado. La identidad de su proceso, los archivos montados, las variables de entorno, las rutas de red y las cuentas de servicio conectadas determinan el radio de impacto. Estos controles se vuelven importantes al reconstruir la exposición antes de aplicar el parche.
La contenerización solo ayuda cuando sus límites se configuran deliberadamente. Un contenedor aún puede acceder a servicios de red, leer secretos montados o enviar datos al exterior. Su seguridad efectiva depende de los permisos de ejecución y de las políticas que lo rodean.
La guía de instalación de GitLab recomienda restringir el acceso saliente a la red para el contenedor de AI Gateway. El control de salida limita los destinos con los que puede comunicarse un proceso comprometido. Puede reducir la utilidad de la ejecución de comandos, aunque no elimina el impacto local.
La segmentación de red proporciona otra capa de contención. Un gateway necesita acceso a endpoints definidos de GitLab y de modelos, pero rara vez necesita alcance sin restricciones por una red interna. Las listas de permitidos limitadas dificultan el movimiento lateral inesperado.
El diseño de credenciales importa por igual. Los secretos de larga duración almacenados directamente en el entorno crean objetivos atractivos tras una explotación. Las credenciales de corta duración, las cuentas de servicio aisladas y los permisos con alcance limitado pueden reducir los daños después de que un servicio se vea comprometido.
Los equipos de seguridad también deberían examinar quién puede crear o modificar flujos personalizados. La documentación de GitLab asigna acciones de gestión de flujos a roles como Maintainer u Owner en varios flujos de trabajo. La exposición exacta sigue dependiendo de la configuración del producto y de la implementación afectada.
El aviso utiliza la expresión más amplia “Duo Agent Platform access” en lugar de nombrar un único rol de proyecto universalmente requerido. Los administradores no deberían convertir los ejemplos de la documentación en un requisito definitivo para la explotación. Deberían revisar los permisos reales y los cambios históricos en los flujos.
El alojamiento propio sigue siendo una opción arquitectónica válida. La lección no es que un servicio gestionado sea siempre más seguro. La lección es que el control de los datos, el control del software y la responsabilidad ante incidentes llegan juntos.
Un gateway gestionado concentra la confianza en las operaciones del proveedor. Un gateway autoalojado concentra la confianza en las tareas de parcheado, aislamiento y supervisión del cliente. CVE-2026-90970 hace visible ese intercambio porque el límite de remediación sigue exactamente el límite de alojamiento.
Para los compradores empresariales, la revisión de seguridad debería cubrir tanto las funciones del producto como la propiedad del despliegue. Las preguntas sobre dónde viajan los datos deberían acompañarse de preguntas sobre quién parchea cada componente. Un diagrama de arquitectura sin propiedad operativa sigue estando incompleto.
Un parche cierra la vulnerabilidad, pero deja preguntas de detección
Actualizar detiene la ruta vulnerable conocida, pero el aviso público no indica a los operadores cómo demostrar que no se produjo una explotación anterior.
A fecha del 4 de octubre, GitLab no había declarado públicamente que CVE-2026-90970 estuviera siendo explotada activamente. Esa ausencia es tranquilizadora, pero no demuestra que todos los despliegues afectados permanecieran intactos.
El detalle técnico público aumenta la importancia de aplicar parches rápidamente. El ticket de divulgación describe la relación entre objetos vulnerable e informa de una ejecución de comandos satisfactoria en un entorno de staging. Tanto defensores como atacantes pueden estudiar ese material.
GitLab atribuyó la divulgación responsable al investigador de HackerOne conocido como invisiblemeerkat. El reporte responsable dio a GitLab tiempo para preparar correcciones y contactar a los clientes afectados. No eliminó la ventana de exposición para los despliegues que siguen sin parchear tras la publicación.
El requisito de autenticación debería orientar la búsqueda de amenazas. Los equipos de seguridad deberían comenzar por las identidades de Duo Agent Platform, los eventos de gestión de flujos y los cambios en las definiciones de flujos personalizados. Deberían correlacionar esos registros con la actividad del gateway durante el período vulnerable.
Las configuraciones inusuales de flujos merecen revisión, especialmente las plantillas que acceden a objetos de historial de conversaciones o invocan métodos. La creación, edición, publicación o ejecución inesperada de flujos puede aportar contexto adicional. Los nombres de flujos aparentemente normales no deberían prevalecer sobre un comportamiento sospechoso de las plantillas.
La actividad de procesos del gateway también importa. Los procesos secundarios, la invocación de shells, los binarios inesperados, el acceso inusual a archivos y las conexiones salientes pueden indicar ejecución de comandos. Los datos útiles dependen de la telemetría de contenedores, hosts y nube que ya esté habilitada.
Los reinicios de contenedores pueden borrar evidencias locales. Por ello, los registros centralizados y la telemetría de seguridad en tiempo de ejecución son más útiles que inspeccionar únicamente un contenedor que está ejecutándose en ese momento. Los equipos deberían conservar los registros disponibles antes de sustituir infraestructura si sospechan de una intrusión.
Los operadores deberían revisar los secretos accesibles para el proceso del gateway. Las decisiones de rotación deberían basarse en evidencias y exposición, no en el pánico. Si los registros indican ejecución de comandos, se debe asumir que las credenciales legibles podrían haber sido accedidas.
Las conexiones del gateway con GitLab y los proveedores de modelos merecen atención independiente. Un atacante que lograra ejecución de comandos podría intentar reutilizar tokens, inspeccionar la configuración o acceder a servicios conectados. El registro público no confirma que se haya producido tal actividad.
El parche no debería marcar el final de la investigación cuando existan pruebas sospechosas. La actualización elimina la ruta de código conocida, pero no revoca credenciales robadas ni deshace cambios realizados en otros lugares. Los procedimientos de respuesta a incidentes siguen siendo necesarios.
También hay una razón histórica para actuar con cautela. Los informes de seguridad identificaron un problema anterior de AI Gateway en 2026, CVE-2026-1868, con la misma puntuación de 9,9 y la misma categoría de debilidad CWE-1336. Esa vulnerabilidad también implicaba contenido de flujos manipulado y posible ejecución de código.
Dos problemas graves en motores de plantillas no demuestran que todos los flujos personalizados sean inseguros. Sí justifican una revisión más exhaustiva de cómo se encuentran las plantillas, los objetos de aplicación y la serialización dentro de los sistemas de agentes.
La recurrencia sugiere que las pruebas de seguridad deben cubrir composiciones, no solo componentes aislados. Un sandbox puede comportarse correctamente frente a cadenas de texto y fallar cuando objetos complejos de un framework entran en su contexto. Un método seguro en una capa puede volverse peligroso cuando las plantillas pueden invocarlo.
Las plataformas de agentes intensifican este problema porque unen muchos mecanismos flexibles. Prompts, herramientas, historiales, lógica de enrutamiento, respuestas de modelos y API de aplicaciones interactúan a través de pasos repetidos. El estado introducido en un paso puede convertirse más tarde en entrada ejecutable.
Las organizaciones deberían añadir flujos personalizados adversariales a las pruebas previas al despliegue. Las pruebas deberían incluir acceso a métodos, recorrido de objetos, límites de serialización y cambios de estado en varios pasos. Un análisis de prompts de una sola pasada no representaría la cadena de explotación reportada.
También deberían tratar las plantillas como artefactos cercanos al código. La revisión, la propiedad, el historial de cambios y los controles de despliegue deberían corresponder a su impacto potencial. Llamar “configuración” a un archivo no reduce su capacidad para modificar el comportamiento en tiempo de ejecución.
GitLab no ha detallado públicamente todas las condiciones necesarias para la explotación. Eso limita una evaluación confiada de la exposición. Los equipos deberían usar los requisitos divulgados como condiciones mínimas, sin asumir que las condiciones no especificadas garantizan la seguridad.
Tres señales mostrarán si la respuesta está funcionando
La siguiente fase depende de la adopción de parches, las pruebas de explotación en el mundo real y un tratamiento más profundo de GitLab sobre el aislamiento de flujos personalizados.
La primera señal es el porcentaje de gateways autoalojados que ejecutan las versiones 19.2.4, 19.3.2, 19.4.1 o una versión posterior corregida. Las organizaciones individuales deberían medirlo en todos los entornos y réplicas. Las cifras de toda la industria podrían seguir sin estar disponibles porque estos despliegues se encuentran dentro de las redes de los clientes.
Una adopción rápida reduciría la superficie de ataque accesible tras la divulgación pública. Una adopción lenta prolongaría el riesgo, especialmente donde los servicios de IA quedan fuera de los inventarios establecidos de gestión de vulnerabilidades. La propiedad del gateway debería hacerse visible en los paneles de parcheado.
La segunda señal es cualquier cambio en el estado de explotación. GitLab, CISA, empresas de respuesta a incidentes y clientes afectados podrían publicar indicadores o casos confirmados. Un informe de explotación activa desplazaría la prioridad del parcheado preventivo hacia una respuesta a incidentes más amplia.
Los defensores deberían distinguir una prueba de concepto pública de ataques observados. La reproducción técnica demuestra que la vulnerabilidad funciona bajo las condiciones documentadas. No establece que los atacantes hayan comprometido clientes de producción.
La tercera señal es un cambio estructural de seguridad en AI Gateway. Un parche limitado puede bloquear la llamada al método divulgada. Una respuesta más amplia podría reducir qué objetos llegan a las plantillas, prohibir serializaciones peligrosas o reforzar el aislamiento en torno a los flujos personalizados.
Esa respuesta de diseño importa porque la cadena reportada surgió de la composición de funciones. Prevenir una carga útil es útil, pero eliminar el límite inseguro de capacidades ofrece una protección más sólida frente a variantes.
Las futuras notas de versión y cambios de código de GitLab deberían aclarar qué capa recibió la corrección. Los administradores deberían vigilar nuevas directrices sobre validación de flujos, eventos de auditoría, consultas de detección y rutas de actualización compatibles para ramas antiguas del gateway.
Los clientes empresariales pueden usar el incidente para poner a prueba ahora su propio modelo operativo. La cuestión importante no es simplemente si GitLab aparece en el inventario de software. Es si AI Gateway existe como un servicio con propietario independiente, parcheado, registrado y aislado.
Los desarrolladores que crean flujos también deberían reconsiderar la confianza asignada a la configuración. Un flujo personalizado puede coordinar herramientas y datos de aplicaciones en múltiples pasos. Debería recibir el mismo escepticismo aplicado a los scripts de automatización y las definiciones de CI.
Los revisores de seguridad deberían mapear cuatro límites: quién puede crear flujos, a qué objetos pueden acceder las plantillas, qué herramientas pueden invocar los flujos y qué privilegios tiene el proceso del gateway. La debilidad en varios límites puede convertir un acceso limitado en control de infraestructura.
Los trabajadores del conocimiento que usan GitLab Duo no necesitan abandonar su trabajo habitual por este aviso. La mayoría no puede determinar por sí misma la propiedad del gateway. Deberían seguir las directrices organizativas e informar de comportamientos inesperados en los flujos, en lugar de intentar pruebas independientes.
Los administradores se enfrentan a una acción más clara. Identifiquen el modelo de alojamiento, confirmen la versión de gateway en ejecución, implementen el parche correcto y conserven evidencias cuando aparezca actividad sospechosa. Revisen los cambios en los flujos y la telemetría del gateway durante el período vulnerable.
Después de aplicar el parche, documenten el resultado en un registro operativo duradero. Registren la versión anterior, la hora del despliegue, los entornos afectados, el método de verificación y cualquier hallazgo de búsqueda de amenazas. Esa evidencia respalda futuras auditorías y la reconstrucción de incidentes.
La vulnerabilidad de GitLab AI Gateway es, en última instancia, una advertencia sobre dónde la lógica de aplicaciones de IA se convierte en software ejecutable convencional. El fallo comenzó en una plantilla de prompt, atravesó un objeto de framework y terminó con comandos del sistema operativo.
Esa ruta merece más atención que la etiqueta “IA” por sí sola. Los modelos pueden influir en los flujos de trabajo, pero los límites convencionales del software siguen decidiendo si una entrada no confiable se convierte en código. Las organizaciones necesitan controles en torno a ambas capas.
Si su organización opera GitLab Duo, plantee hoy una pregunta concreta: ¿quién es propietario del gateway que procesa esas solicitudes? Si la respuesta es su equipo, verifique su versión frente a las versiones corregidas de GitLab. Después, pruebe si su monitorización revelaría comandos inesperados, flujos modificados o conexiones salientes. El parche cierra la vulnerabilidad divulgada de GitLab AI Gateway, pero una seguridad duradera depende de inventario, aislamiento y evidencias que sobrevivan al próximo aviso.
