El catálogo de vulnerabilidades explotadas de CISA no sumó entradas en los últimos 2 días, así que la nota de hoy sale de otro lado y es distinta de las de toda la semana: esta falla todavía no se está explotando, y la evaluación de CISA sobre ella dice, en su casilla de explotación, ninguna. GitLab la publicó hace 2 días, el 2 de octubre.
Eso la vuelve interesante por otro motivo. Es la primera vulnerabilidad crítica verificada en la capa de inteligencia artificial de una plataforma de desarrollo que mucha gente de la región instala en su propio servidor, y pone un número concreto a una decisión que muchas organizaciones tomaron sin pensarla mucho: encender el asistente de IA.
GitLab publicó la corrección y le asignó 9,9 crítica. El título del arreglo, textual: "Improper Neutralization issue in custom flow prompt template impacts AI Gateway".
Cómo CVE-2026-90970 escapa de la plantilla de prompt y ejecuta comandos
La descripción del fabricante es precisa y vale leerla entera: la falla "could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway".
Vale subrayar ese último punto porque es lo que conviene llevarse de la nota. Un prompt es texto, y una plantilla de prompt es texto con huecos donde se insertan datos. En el momento en que un dato controlado por el usuario se inserta en una plantilla y el motor lo interpreta en lugar de tratarlo como contenido, estamos frente al mismo error de siempre, el de confundir dato con instrucción. Es el abuelo de la inyección SQL y de la inyección de comandos.
Lo que la capa de IA agrega no es una clase de falla nueva: agrega una superficie nueva donde la clase vieja vuelve a aparecer, en un componente que suele instalarse con permisos amplios porque tiene que poder hacer cosas por el usuario.
Y para que quede claro el alcance de esta nota: expliqué el mecanismo, no publico ninguna configuración de ejemplo. El aviso de GitLab tampoco la publica.
CWE-1336 llegó 3 veces al catálogo, y las 3 veces ya estaba explotada
Acá está el argumento para no dejarlo para después, y sale de medir el catálogo en vez de suponer.
La inyección en motor de plantillas es rara en el catálogo: solo 3 entradas en toda su historia. Pero las 3 llegaron ahí por el mismo camino, que es haber sido explotadas en el mundo real, y dos de ellas —CrushFTP y el servidor de archivos de Rejetto— fueron casos de explotación masiva bien documentados. La tercera es la de Adobe Commerce que este sitio cubrió en septiembre.
Las 3 aparecieron repartidas en 28 meses, lo que da la medida de lo infrecuente que es la clase. Para ubicar también al producto: GitLab acumula 5 entradas en el catálogo, y la última entró hace 23 días.
De una muestra de 3 no se saca una ley, y conviene decirlo así. Lo que sí se puede decir es que no hay en el catálogo ningún precedente de esta clase que haya quedado sin usar, y que un escape de plantilla que termina en ejecución de comandos es exactamente el tipo de hallazgo que alguien reproduce a partir del parche.
Por qué 9,9 si hace falta estar autenticado
El vector que publicó GitLab explica el número, y vale desarmarlo porque a primera vista no cierra: si el atacante necesita una cuenta, ¿cómo llega a 9,9?
Dos piezas del vector lo responden. La primera: los privilegios requeridos están en bajos, no en altos. No hace falta ser administrador, hace falta ser un usuario con acceso a la plataforma de agentes, que en un equipo de desarrollo puede ser cualquiera que escriba código. La segunda, y es la que levanta el puntaje: el alcance está marcado como cambiado, que es la forma en que la escala dice que el daño sale del componente vulnerable y afecta a otra cosa. Un comando ejecutado en el servidor del AI Gateway no se queda en el AI Gateway.
Esto es lo contrario del caso de la falla de Apple de la semana pasada, donde el puntaje de 8,8 lo puso CISA y no el fabricante. Acá el 9,9 es de GitLab como autoridad de numeración, y NVD todavía tiene la ficha en análisis pendiente, así que el número que vas a ver es el del fabricante.
¿A quién afecta CVE-2026-90970 del AI Gateway?
Solo a instalaciones propias. GitLab lo dice sin rodeos en el aviso: "A fix has already been deployed for GitLab-hosted AI Gateways". Si usás GitLab.com, no tenés nada que hacer.
Si tenés GitLab en tu servidor y además levantaste el AI Gateway autoalojado, te toca. Las versiones afectadas son de la 18.1.6 hasta antes de la 19.2.4, la rama 19.3 antes de la 19.3.2 y la rama 19.4 antes de la 19.4.1.
Y hay una condición más que hace a la mayoría de los lectores: si nunca encendiste la plataforma de agentes Duo, no tenés el componente. El AI Gateway no viene andando por defecto en una instalación de GitLab: es algo que se instala y se configura aparte. Es otra versión del mismo razonamiento que el sitio viene haciendo con Zimbra y TrueConf y ayer con la mesa de ayuda Zammad: lo que instalás vos, lo mantenés vos.
¿Quién puede ignorar el aviso del AI Gateway?
Quien use GitLab.com, porque ya está corregido del lado del proveedor.
Quien tenga GitLab autoalojado sin el AI Gateway levantado, que probablemente sea la mayoría.
Y quien ya esté en 19.2.4, 19.3.2 o 19.4.1 del AI Gateway, según la rama.
Lo que no alcanza para ignorarlo: que la falla pida un usuario autenticado. En un GitLab de empresa, la gente del equipo de desarrollo está autenticada por definición, y en muchos casos también están autenticados contratistas y colaboradores externos. "Hace falta una cuenta" no es una barrera cuando las cuentas son el modelo de uso del producto.
¿Cómo sé qué versión de mi AI Gateway tengo?
Acá hay una trampa concreta que conviene conocer antes de mirar, y es la razón principal por la que vale la pena esta nota si tenés el componente.
El AI Gateway se versiona y se actualiza por separado de GitLab CE y EE. Los números se parecen y en algunos casos coinciden, lo que invita al error: existe una versión 19.2.4 de GitLab CE/EE y existe una versión 19.2.4 del AI Gateway, y son cosas distintas que se publicaron en momentos distintos.
O sea que mirar la versión de tu GitLab no responde esta pregunta. Hay que mirar la del AI Gateway, que es un servicio aparte, con su propio despliegue y su propia documentación de instalación. Si administrás esto con contenedores, la respuesta está en la etiqueta de la imagen del AI Gateway, no en la de GitLab.
Para la segunda pregunta, la de si alguien lo usó: como la falla termina en ejecución de comandos en el servidor del AI Gateway, lo que hay que revisar es ese servidor, no GitLab. Procesos y conexiones de salida que no correspondan, y archivos nuevos. Y los registros de configuraciones de flujo creadas o modificadas, con quién las creó. Vale la aclaración honesta: al no haber explotación conocida, no hay indicadores publicados que buscar, así que esto es revisión general y no búsqueda de un patrón concreto.
¿Qué hago si tengo el AI Gateway autoalojado?
- Confirmá primero si lo tenés. Es la pregunta que más gente va a responder con un "no" y ahí termina el trabajo. Mirá si la plataforma de agentes Duo está habilitada y si hay un servicio de AI Gateway desplegado.
- Si lo tenés, mirá su versión, no la de GitLab. Son numeraciones distintas.
- Actualizá a 19.2.4, 19.3.2 o 19.4.1 según la rama, siguiendo la documentación de instalación del AI Gateway autoalojado, que es el camino que indica el fabricante.
- Revisá quién tiene acceso a la plataforma de agentes. Esta falla convierte "acceso al agente de IA" en una capacidad sensible, así que vale revisar si ese permiso está dado por costumbre a gente que no lo necesita, incluidos usuarios externos.
- Tratá al AI Gateway como un servicio más del inventario. Si apareció en tu infraestructura por una prueba que quedó andando, esta es la señal para decidir si se queda con mantenimiento o se apaga.
El punto 5 es el que más vale repetir. La capa de IA llegó rápido a muchas organizaciones y en bastantes casos entró como experimento, sin dueño y sin estar en la lista de cosas que alguien actualiza. Es el mismo problema que el sitio planteó al cubrir cómo un grupo de ransomware usó un asistente de código para planear intrusiones, visto del otro lado: no solo hay que pensar qué hacen los atacantes con la IA, también qué agregamos nosotros a la superficie de ataque al adoptarla.
Los términos están en el glosario, y la otra falla de GitLab que el sitio cubrió este mes, en GitLab CVE-2026-85706.
Preguntas frecuentes sobre CVE-2026-90970 y el AI Gateway
Si no se está explotando, ¿por qué actualizar ya?
Porque el parche publica el problema. Una vez que la corrección está afuera, se puede comparar el código anterior con el nuevo y deducir el camino. Sumale que esta clase de falla —inyección en motor de plantillas— aparece 3 veces en toda la historia del catálogo de vulnerabilidades explotadas, y las 3 veces llegó ahí por haber sido usada en ataques reales. Es una muestra chica para hablar de probabilidades, pero no hay ningún precedente de esta clase que haya quedado sin usar.
Uso GitLab.com. ¿Tengo que hacer algo?
No. El aviso dice que la corrección ya se desplegó en los AI Gateway alojados por GitLab. Esta falla es un problema de instalaciones propias, y es una de las pocas veces en que la respuesta para quien usa el servicio en la nube es literalmente ninguna acción.
Mi GitLab está en la versión 19.4.1. ¿Eso me cubre?
No necesariamente, y esta es la confusión más probable de todo el aviso. El AI Gateway se versiona aparte de GitLab CE y EE, y los números coinciden parcialmente: hay una 19.4.1 de GitLab y una 19.4.1 del AI Gateway, publicadas por separado. Estar en la 19.4.1 de GitLab no dice nada sobre la versión de tu AI Gateway. Hay que mirar la del componente.
¿Esto significa que no conviene habilitar funciones de IA?
No es la conclusión. Lo que muestra el caso es que la capa de IA es software como cualquier otro: tiene componentes, versiones, fallas y parches, y necesita entrar al inventario de cosas que alguien actualiza. El problema no es encenderla, es encenderla como experimento y olvidarse de que quedó andando. Antes de habilitarla, las preguntas útiles son quién la va a mantener, quién va a tener acceso y cómo te vas a enterar de que salió un parche.
¿Un usuario con pocos permisos puede explotarla?
Según el vector que publicó GitLab, los privilegios requeridos son bajos: no hace falta ser administrador, hace falta tener acceso a la plataforma de agentes Duo. En un equipo de desarrollo ese acceso suele estar dado de forma amplia porque es parte del trabajo diario. Por eso, además de actualizar, conviene revisar a quiénes se les dio ese permiso, sobre todo si hay colaboradores externos con cuenta en tu instancia.