Índice de contenidos
Claves de la noticia
- GitLab ha divulgado CVE-2026-90970, un fallo crítico que permite ejecutar comandos en AI Gateway bajo determinadas condiciones.
- Las versiones corregidas del componente son 19.2.4, 19.3.2 y 19.4.1; el ataque requiere autenticación y acceso a Duo Agent Platform.
- El inventario debe distinguir quién mantiene la pasarela: tener GitLab instalado en servidores propios no implica alojar también AI Gateway.
GitLab ha publicado este 2 de octubre una vulnerabilidad de su infraestructura de inteligencia artificial que obliga a revisar algo más que la versión del servidor de repositorios. La alerta afecta a AI Gateway, el servicio que conecta las funciones de GitLab Duo con los modelos. Para determinar qué actualizar hay que localizar esa pasarela y comprobar cómo se ejecutan las funciones de agentes.
Una configuración de flujo podía romper el aislamiento
El registro CVE publicado por GitLab describe una salida del entorno aislado de las plantillas de instrucciones mediante una configuración de flujo preparada especialmente. El resultado posible es ejecutar comandos arbitrarios en AI Gateway. La puntuación del fabricante es 9,9 sobre 10 en CVSS 3.1, con complejidad baja y privilegios bajos. No describe un ataque anónimo: exige un usuario autenticado con acceso a Duo Agent Platform.
La debilidad está clasificada como CWE-1336. Según la definición técnica de MITRE, aparece cuando un motor de plantillas interpreta como expresiones o instrucciones elementos que llegan desde una entrada externa y no se neutralizan correctamente. Es un problema del procesamiento de plantillas; no equivale a demostrar que un modelo de lenguaje haya decidido atacar el sistema por sí solo.
Esta distinción cambia la lectura del incidente. La frontera comprometida es la que debía separar una configuración aceptada por el servicio de instrucciones ejecutables en su entorno. El análisis no permite deducir un robo de repositorios, una intrusión concreta ni el control completo de toda una empresa. Esos escenarios requerirían evidencias adicionales sobre permisos, conexiones y actividad observada.
Las tres ramas con corrección
La ficha del fabricante identifica los siguientes intervalos afectados y sus versiones de salida. Los números se refieren al componente AI Gateway y deben contrastarse con la imagen que está desplegada, no solo con el panel general de GitLab.
| Intervalo afectado | Corrección indicada |
|---|---|
| Desde 18.1.6 y antes de 19.2.4 | 19.2.4 o posterior |
| 19.3 y antes de 19.3.2 | 19.3.2 o posterior |
| 19.4 y antes de 19.4.1 | 19.4.1 o posterior |
El registro público incluye una evaluación de CISA que, a las 16:47 UTC del 2 de octubre, marcaba la explotación como no observada. Esa anotación temporal no garantiza que nadie pueda aprovechar el fallo ni reduce su gravedad. Tampoco justifica presentar como confirmada una campaña de ataques que las fuentes consultadas no documentan.
Servidor propio y pasarela propia son decisiones diferentes
La documentación de configuración establece dos opciones para clientes de GitLab Self-Managed: usar la pasarela gestionada por GitLab o desplegar una propia. La primera es la configuración predeterminada. Por tanto, localizar una instalación empresarial de GitLab en un centro de datos no basta para incluirla automáticamente entre las pasarelas que deben mantener sus administradores.
Según la alerta recogida por BleepingComputer, el servicio alojado por GitLab ya está protegido y sus usuarios no tienen que aplicar esta corrección en esa pasarela. El medio también recoge que la compañía contactó previamente con clientes que mantienen AI Gateway por su cuenta. La diferencia operativa está en quién administra el componente vulnerable.
Al cruzar el aviso con la arquitectura documentada aparece una conclusión concreta: la ubicación del servidor GitLab y la del modelo no identifican por sí solas al responsable del parche. La pregunta decisiva es qué AI Gateway recibe el flujo. Un proveedor de modelos externo puede estar detrás de una pasarela que la empresa debe actualizar por su cuenta.
El modo híbrido exige revisar cada función
GitLab admite configuraciones híbridas en las que algunas funciones utilizan modelos propios y otras emplean modelos gestionados. Su guía de modelos autoalojados explica que las funciones configuradas con modelos gestionados por GitLab envían sus solicitudes a la pasarela de GitLab. Las que usan el circuito propio siguen otro recorrido.
Esto impide clasificar toda la instalación como protegida porque una función concreta termine en el servicio gestionado. Para equipos que combinan opciones, el inventario útil relaciona función, pasarela y versión. Esa comprobación evita tanto una actualización innecesaria del servicio equivocado como dejar sin revisar el componente que sigue bajo mantenimiento local.
La enseñanza enlaza con el problema más amplio de limitar los permisos de los agentes: una etiqueta comercial de inteligencia artificial no sustituye la descripción de sus fronteras de ejecución. En este caso, la frontera se puede localizar en un servicio y una versión concretos.
Comprobar la imagen antes de dar el trabajo por terminado
La guía de instalación de AI Gateway utiliza imágenes independientes con etiquetas de versión explícitas. Recomienda elegir una versión estable de la rama correspondiente a la instancia GitLab. De ahí se desprende una segunda comprobación práctica: actualizar el servidor de repositorios no demuestra que haya cambiado el contenedor de la pasarela.
El cierre del mantenimiento requiere verificar la imagen realmente ejecutada y comprobar después que las funciones Duo siguen disponibles. GitLab también documenta restricciones de conexiones salientes para ese contenedor. Son medidas de endurecimiento que deben probarse para no cortar dependencias necesarias; no sustituyen la corrección de la vulnerabilidad.
Para un equipo español que haya elegido alojar su infraestructura de IA por privacidad o control, el aviso concreta el coste de esa elección: el aislamiento de datos debe ir acompañado del mantenimiento del servicio que procesa los flujos. La decisión útil hoy consiste en identificar esa pasarela, aplicar la versión corregida compatible y verificar el despliegue, sin confundir el proveedor del modelo con el responsable de actualizarla.
Imagen: Tecnología Today / imagen generada. Escena conceptual de mantenimiento, no fotografía de una instalación de GitLab.
