CVE-2026-90970: GitLab AI Gateway, CVSS 9.9, qué hacer HOY

octubre 5, 2026 Alfonso Moreno | Sysadmin Senior 33 Visitas 10 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué este parche importa hoy

GitLab publicó el 2 de octubre de 2026 un parche crítico para su AI Gateway, el servicio que conecta tu instancia con los modelos que sostienen GitLab Duo (chat, code suggestions y el Duo Agent Platform). El fallo, registrado como CVE-2026-90970, tiene CVSS 9.9 y permite a un usuario autenticado con acceso a Duo Agent Platform escapar del sandbox del template de prompts y ejecutar comandos arbitrarios dentro del gateway.

Si tu organización usa GitLab Duo Self-Hosted con AI Gateway on-prem, este parche te toca directamente. Si usas GitLab.com, GitLab Dedicated o GitLab Self-Managed con el gateway hospedado por GitLab, ya estás protegido: GitLab desplegó el fix en sus gateways administrados sin que tengas que hacer nada.

El aviso vino por el investigador invisiblemeerkat a través de HackerOne, y la categoría técnica del fallo es CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine), la misma clase de bug que la GitLab ya intentó cerrar en febrero de 2026 con CVE-2026-1868. Que reaparezca seis meses después con el mismo vector (template engine + Duo Agent Platform flow definitions) sugiere que el sandboxing del AI Gateway sigue siendo un punto caliente y conviene tratarlo como tal en tu threat model interno, no como un parche más.

Qué se rompió exactamente

El AI Gateway procesa definiciones JSON/YAML que GitLab Duo Agent Platform envía para construir los prompts que finalmente llegan al modelo. Cada flujo tiene secciones con {{...}} que el gateway expande usando un motor de templates propio. La validación correcta de esos placeholders es lo único que separa un prompt LLM de un shell.

CVE-2026-90970 ocurre porque, en versiones afectadas, un usuario autenticado puede construir una definición de flow con placeholders especialmente diseñados que el motor de templates no neutraliza antes de expandir. Al expandirse, esos placeholders se convierten en invocaciones que el gateway ejecuta a nivel de sistema operativo con sus propios privilegios. No es RCE sobre el modelo; es RCE sobre el contenedor o la VM donde corre el AI Gateway, que es donde viven los secretos que el gateway necesita para funcionar.

La cadena completa, en términos de atacante:

1. Atacante ya está autenticado en GitLab con acceso a Duo Agent Platform.
2. Crea/edita un flow con placeholders maliciosos en la sección de prompts.
3. GitLab envía el flow al AI Gateway self-hosted para expandirlo.
4. El motor de templates expande placeholders sin neutralizar.
5. El payload se ejecuta como proceso dentro del AI Gateway.
6. El atacante hereda los secretos del gateway y la red del host.

El vector requiere autenticación válida, así que no es wormable: alguien con un token de Duo Agent Platform debe disparar la acción. Pero ese token puede ser un bot, una cuenta de servicio con scopes amplios, o una cuenta corporativa comprometida en el pipeline CI/CD. En cualquier despliegue mediano es razonable asumir que la superficie existe.

Qué está afectado y qué no

El rango afectado según el registro oficial de CVE y el release notes de GitLab es:

Rama del AI Gateway	Versiones afectadas	Versión parcheada
19.4.x	19.4.0	19.4.1
19.3.x	19.3.0, 19.3.1	19.3.2
18.x / 19.0-19.2	desde 18.1.6 hasta 19.2.3	19.2.4

El vector de ataque se documenta como CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: red, complejidad baja, requiere privilegios, sin interacción, con impacto en confidencialidad, integridad y disponibilidad. El S:C (Scope Changed) es lo que lo hace 9.9 y no 8.x: el bug escapa del componente Duo y compromete el host del gateway.

Si tu gateway lo hospeda GitLab (SaaS, Dedicated o Self-Managed conectado al gateway cloud), no hay acción: GitLab ya parchó. Si tu gateway lo hospeda tu organización sobre Docker, Kubernetes o Helm, te toca actualizar. Y si tienes una versión fuera de las ramas soportadas (18.0.x y anteriores, o 19.1.x con LTS terminado), la única salida de git válida es migrar a una rama parcheada.

Cómo actualizar el AI Gateway self-hosted

El procedimiento oficial documenta dos rutas: Docker standalone y Helm chart sobre Kubernetes. La elección entre una y la otra depende de tu despliegue actual.

Ruta Docker standalone: es la que usa la mayoría de equipos que tienen el gateway en una VM Linux aparte. El flujo es exactamente el que documenta GitLab para actualizaciones:

# 1. Identifica el contenedor actual
sudo docker ps --filter name=gitlab-aigw --format "{{.ID}} {{.Image}}"
# 2. Detén el contenedor
sudo docker stop gitlab-aigw
# 3. Elimina el contenedor (NO la imagen, NO los volúmenes)
sudo docker rm gitlab-aigw
# 4. Pull del nuevo tag. Elige el que coincida con tu rama soportada:
#    v19.4.1-ee si vienes de 19.4
#    v19.3.2-ee si vienes de 19.3
#    v19.2.4-ee si vienes de 18.x / 19.0-19.2
sudo docker pull registry.gitlab.com/gitlab-org/ai-gateway/self-hosted-v19.4.1-ee
# 5. Vuelve a levantarlo con los mismos -e y --add-host del contenedor viejo.
#    Recupera la línea de creación con:
sudo docker inspect gitlab-aigw --format "{{.Args}} {{.Env}} {{.HostConfig.ExtraHosts}}"
# 6. Verifica que el contenedor arranca y el healthcheck responde
sudo docker run -d --name gitlab-aigw 
  --restart always 
  -p 5000:5000 
  -e AIGW_LOG_LEVEL=INFO 
  -e AIGW_GITLAB_URL=https://gitlab.tu-empresa.example 
  -e AIGW_GITLAB_API_URL=https://gitlab.tu-empresa.example/api/v4 
  registry.gitlab.com/gitlab-org/ai-gateway/self-hosted-v19.4.1-ee

El comando clave es docker inspect antes de borrar el contenedor viejo: si tienes un script de IaC externo (Terraform, Ansible, NixOS) el output debería coincidir, pero si el contenedor se creó a mano, esa es la única forma de no perder variables de runtime como AIGW_GITLAB_API_URL, el path al bundle de certificados o las claves de firmado de JWT que el gateway necesita para validar tokens emitidos por GitLab.

Ruta Helm chart sobre Kubernetes: aplica para despliegues tipo GitLab Operator o Helm chart propio. Aquí conviene fijar imagePullPolicy: Always para que un cambio de tag en values.yaml realmente haga pull la próxima vez:

# 1. Edita values.yaml del chart ai-gateway
helm get values gitlab-aigw -n gitlab > values-current.yaml
# - cambia la versión de la imagen a 19.4.1-ee
# - deja imagePullPolicy: Always
# 2. Upgrade atómico
helm upgrade gitlab-aigw gitlab/ai-gateway 
  -n gitlab 
  -f values-current.yaml 
  --atomic 
  --wait
# 3. Verifica rollout
kubectl rollout status deployment/gitlab-aigw -n gitlab
# 4. Comprueba que el pod arrancó con la nueva imagen
kubectl get pod -n gitlab -l app=ai-gateway 
  -o jsonpath='{.items[*].spec.containers[?(@.name=="ai-gateway")].image}{"n"}'

--atomic es importante aquí: si la nueva versión falla el healthcheck, Helm revierte automáticamente a la revisión anterior en lugar de dejarte con un gateway caído. --wait bloquea hasta que el rollout esté completo o timeout, lo que te da una señal clara de éxito o fracaso sin tener que hacer polling manual.

Comprobaciones post-actualización

Antes de dar por cerrado el trabajo, valida tres cosas que indican que el gateway actualizado está sirviendo tráfico real, no un zombie en crash loop.

1. Versión reportada por el propio gateway. El endpoint /version o los health endpoints según el build deberían reflejar la nueva versión. Si tu gateway expone Prometheus metrics en el puerto interno, también puedes verificar que arrancó sin errores de inicio:

# Desde el host del gateway o un pod con acceso a su red interna
curl -sS http://localhost:5000/version | jq '.version, .commit_sha'
# Esperado: "19.4.1" y un SHA corto de 9 caracteres
# Logs de arranque recientes
sudo docker logs --tail 200 gitlab-aigw | grep -E 'startup|version|listening'

2. Funcionamiento end-to-end con Duo. El test real es que un flow que antes tardaba 2-3 segundos en responder ahora siga funcionando. Desde GitLab UI, abre un proyecto con Duo Agent Platform habilitado y lanza un flow pequeño (por ejemplo pedir al agente que resuma un MR). Si el flow arranca y devuelve respuesta, el gateway está hablando correctamente con la instancia de GitLab y con el backend de modelos.

3. No hay flows viejos persistidos que re-introduzcan el riesgo. Este punto es el que más equipos se saltan: el bug vive en cómo el gateway procesa flows definidos por usuarios. Si tienes definiciones JSON de flows en Git, en CI variables, o exportadas de instancias de Duo, vale la pena revisar quién puede modificarlas. El atacante necesita escribir el flow antes de pedir que se ejecute.

Por qué este bug es más serio de lo que parece

El AI Gateway self-hosted maneja credenciales sensibles que lo identifican ante tu instancia de GitLab. Por la documentación oficial, entre las variables de entorno obligatorias están las claves de firmado y validación de JSON Web Tokens (AIGW_JWT_SIGNING_KEY, AIGW_JWT_PUBLIC_KEY) y la URL interna del API de GitLab. Un atacante que ejecute código en el gateway obtiene:

Acceso de lectura a todas esas variables, que puede reutilizar para impersonar al gateway ante GitLab.
Acceso de red al endpoint del API interno de GitLab (AIGW_GITLAB_API_URL), típicamente en la red interna donde está la instancia principal.
Si la AI Gateway comparte host con otros servicios (un patrón todavía común en homelabs), pivotaje lateral hacia esos servicios.

Esa combinación (claves de JWT + acceso al API interno) es exactamente el tipo de foothold que los equipos de red quieren evitar en su segmento de CI/CD. La CVSS 9.9 refleja ese alcance, no el detalle técnico del escape de template.

Otro ángulo a considerar: no hay evidencia pública de explotación in-the-wild según el aviso del 2 de octubre de GitLab. Pero la clase de bug (template engine con CWE-1336) ya apareció antes en CVE-2026-1868 y volvió a aparecer seis meses después con el mismo vector. Eso es una señal para que los equipos de seguridad internos clasifiquen las próximas advisories de AI Gateway como prioridad alta por defecto, no esperar al CVSS exacto del próximo aviso.

Vale la pena actualizar, ¿para quién?

Sí, sin discusión, si tu gateway es self-hosted y está dentro de las ramas afectadas. El procedimiento es de minutos en Docker y de un upgrade atómico en Helm. No hay breaking changes anunciados en el release notes que cambien la configuración del usuario final, solo el fix de seguridad.

Para equipos que usan GitLab.com o GitLab Dedicated: nada que hacer. El gateway administrado por GitLab ya está parcheado desde el 2 de octubre.

Para equipos en ramas muy viejas (18.0.x, 19.1.x con LTS terminado): este parche es la palanca para migrar. Las versiones parcheadas (19.2.4, 19.3.2, 19.4.1) son las únicas ramas soportadas en adelante según el release notes, así que posponer la migración acumula riesgo técnico y de seguridad.

Como acción complementaria, no relacionada con el parche pero relevante para la superficie: revisa quién tiene acceso a Duo Agent Platform en tu instancia. El bug requiere autenticación válida, así que reducir el círculo de usuarios con ese permiso reduce el círculo de atacantes potenciales. En GitLab Self-Managed esto se gestiona en Admin → GitLab Duo y por grupo/proyecto.

Preguntas frecuentes

¿Por qué CVE-2026-90970: GitLab AI Gateway, CVSS 9.9, qué hacer HOY es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con CVE-2026-90970: GitLab AI Gateway, CVSS?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con CVE-2026-90970: GitLab AI Gateway, CVSS?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar CVE-2026-90970: GitLab AI Gateway, CVSS y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a CVE-2026-90970: GitLab AI Gateway, CVSS?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.