La vulnerabilidad de GitLab AI Gateway convierte el acceso autorizado a Duo en un riesgo crítico de RCE

GitLab ha corregido una vulnerabilidad de GitLab AI Gateway con una puntuación de 9,9 que puede convertir el acceso autorizado a Duo Agent Platform en ejecución de comandos en un gateway autohospedado. El fallo, identificado como CVE-2026-90970, atraviesa un límite que el producto debía aplicar. Una configuración de flujo especialmente diseñada puede escapar del sandbox de plantillas de prompts y ejecutar comandos arbitrarios en el gateway.

Esta precisión importa. No se trata de un compromiso zero-click reportado contra todos los servidores de GitLab, ni otorga acceso inmediato a un usuario anónimo de internet. La explotación requiere autenticación y acceso a Duo Agent Platform. Sin embargo, la evaluación de gravedad de GitLab refleja lo que ocurre una vez se cumplen estas condiciones: explotación de red de baja complejidad, sin interacción adicional del usuario y con consecuencias potencialmente graves para la confidencialidad, integridad y disponibilidad.

El incidente genera un conflicto directo entre control y responsabilidad. Las organizaciones autohospedan infraestructura de IA para mantener el código, los prompts y el tráfico de modelos dentro de límites de confianza. Sin embargo, el autohospedaje también las hace responsables de actualizar el servicio que procesa este material sensible. Los gateways alojados por GitLab ya han sido corregidos, mientras que los operadores de gateways autohospedados afectados deben realizar sus propias actualizaciones.

Qué cambió con la vulnerabilidad de GitLab AI Gateway

CVE-2026-90970 convierte el permiso para configurar un flujo de trabajo de IA en una posible vía hacia comandos del sistema operativo.

GitLab divulgó el problema el 2 de octubre de 2026. Según el registro público de la vulnerabilidad, las versiones afectadas incluyen AI Gateway desde la 18.1.6 hasta las versiones anteriores a la 19.2.4. La rama 19.3 está afectada antes de la 19.3.2, mientras que la rama 19.4 lo está antes de la 19.4.1.

Estos límites de versiones difieren del historial de lanzamientos de la aplicación principal de GitLab. Por ello, los administradores deben verificar la imagen o el despliegue de AI Gateway propiamente dicho. Comprobar únicamente la versión visible de la aplicación GitLab puede generar una falsa sensación de seguridad cuando el gateway sigue un ciclo de despliegue independiente.

Las versiones corregidas son 19.2.4, 19.3.2 y 19.4.1. Los operadores deben pasar a la versión corregida correspondiente o a una versión posterior compatible. Los gateways alojados por GitLab ya han recibido la corrección, por lo que GitLab.com y los clientes que usan el gateway gestionado de GitLab no enfrentan la misma tarea de parcheo.

La ruta vulnerable comienza con una configuración de flujo especialmente elaborada. Un flujo define una secuencia agéntica que puede combinar prompts, herramientas, decisiones y acciones. GitLab Duo Agent Platform utiliza estas configuraciones para realizar tareas de desarrollo de software de varios pasos, en lugar de responder a un único prompt aislado.

Las plantillas de prompts convierten la configuración de un flujo y sus datos de ejecución en instrucciones que un modelo de IA puede procesar. Un sandbox de plantillas es el entorno restringido diseñado para impedir que el contenido de las plantillas alcance capacidades inseguras de la aplicación o del sistema operativo. CVE-2026-90970 implica una neutralización inadecuada dentro de ese límite.

La debilidad se clasifica como CWE-1336, o neutralización inadecuada de elementos especiales utilizados en un motor de plantillas. En términos prácticos, la sintaxis controlada por un atacante puede interpretarse como comportamiento ejecutable de la plantilla en lugar de datos inertes. El resultado peligroso exacto depende de la aplicación circundante, las funciones disponibles y los privilegios del proceso.

En este fallo, GitLab afirma que el resultado puede ser la ejecución arbitraria de comandos en AI Gateway. Ese resultado es más grave que manipular una respuesta de IA. Significa que la vulnerabilidad va más allá de la salida del modelo y alcanza el entorno de ejecución convencional que aloja el gateway.

La distinción entre AI Gateway y un modelo de lenguaje de gran tamaño es importante. El gateway es un servicio de aplicación independiente situado entre las funcionalidades de GitLab y los modelos de IA. La documentación del gateway de GitLab indica que el servicio proporciona acceso a funcionalidades nativas de IA de GitLab Duo. Gestiona la lógica de la aplicación y las solicitudes relacionadas con el modelo, en lugar de funcionar como el propio modelo.

Por consiguiente, la vulnerabilidad no demuestra que un modelo haya descubierto de forma independiente una vía de escape o ignorado una instrucción de seguridad conductual. El mecanismo reportado es una vulnerabilidad de software en el procesamiento de plantillas. Su entrada llega a través de una superficie de configuración agéntica.

Ese hecho mantiene el incidente dentro de una categoría de seguridad conocida, pero el contexto eleva lo que está en juego. Los gateways de IA pueden manejar contexto derivado del código fuente, instrucciones de flujos de trabajo, material de autenticación y conexiones con backends de modelos. Un fallo de ejecución de comandos en ese punto de unión puede exponer más que un prompt malformado o una respuesta poco fiable.

GitLab no ha descrito públicamente una explotación generalizada de CVE-2026-90970. El registro disponible tampoco establece que atacantes hayan usado la vulnerabilidad contra entornos de producción. Los administradores no deben interpretar esa falta de verificación como prueba de seguridad, especialmente después de que la divulgación ofrezca a potenciales atacantes un objetivo más claro.

Por tanto, el cambio inmediato es operativo. Un AI Gateway autohospedado que antes se consideraba un componente interno controlado ahora exige verificación urgente de versión, parcheo y revisión posterior a la actualización. Su riesgo no puede inferirse únicamente de si la interfaz principal de GitLab es pública.

Por qué una fuga del sandbox autenticada merece una puntuación de 9,9

La vulnerabilidad es crítica porque sus requisitos previos limitan quién puede atacar, mientras que su impacto potencial sigue siendo amplio una vez que el sandbox falla.

GitLab asignó a CVE-2026-90970 una puntuación base CVSS 3.1 de 9,9. El vector publicado es AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Cada elemento explica por qué un fallo autenticado puede seguir situándose cerca de la parte superior de la escala de gravedad.

El vector de ataque de red significa que un atacante potencial no necesita acceso local de shell al host del gateway. El servicio relevante puede recibir la configuración maliciosa mediante funcionalidades de aplicación accesibles por red. Accesible por red no implica necesariamente exposición a toda la internet pública, pero amplía la posible vía de ataque más allá del acceso físico o local.

La baja complejidad del ataque indica que la explotación no depende de una condición de carrera limitada ni de un estado de despliegue inusual. Se requieren privilegios bajos, no ausencia de privilegios. El usuario debe estar autenticado y tener acceso a Duo Agent Platform.

La ausencia de interacción del usuario significa que otra persona no necesita abrir un archivo, aprobar un diálogo ni visitar un enlace malicioso después de que la configuración alcance la ruta vulnerable. Esta característica importa en entornos colaborativos de desarrollo, donde la automatización de confianza suele procesar configuraciones enviadas sin una segunda acción humana.

El componente de alcance cambiado es especialmente significativo. Indica que la explotación puede afectar a recursos que van más allá de la autoridad de seguridad representada por el componente vulnerable original. Aquí, la entrada de la plantilla comienza dentro de un flujo de trabajo agéntico autorizado, pero puede cruzar al entorno de ejecución de comandos del gateway.

Las tres métricas finales registran un alto impacto potencial sobre la confidencialidad, integridad y disponibilidad. La ejecución de comandos puede, en teoría, permitir leer información accesible, modificar recursos del gateway o interrumpir el servicio. El daño real sigue dependiendo de la arquitectura de despliegue, los permisos del proceso, la accesibilidad de red y las credenciales disponibles.

Ese contexto evita dos interpretaciones engañosas. Calificar la vulnerabilidad como “autenticada” no debe utilizarse para descartarla como un problema ordinario a nivel de cuenta. Calificarla como “ejecución remota de código” no debe implicar que cualquier visitante anónimo pueda comprometer inmediatamente un entorno GitLab.

El atacante relevante podría ya ser un usuario válido. También podría ser alguien que controle una cuenta comprometida, un token robado o una identidad de automatización con privilegios excesivos. Los límites de seguridad deben seguir funcionando después de la autenticación, ya que el acceso legítimo rara vez equivale a autoridad ilimitada sobre la infraestructura.

Los sistemas de agentes hacen que esta distinción sea más urgente. Aceptan instrucciones estructuradas y pueden realizar secuencias de acciones entre servicios de desarrollo. Un usuario autorizado para definir un flujo puede necesitar amplias capacidades de aplicación, pero no debería heredar los privilegios del sistema operativo del servicio que interpreta el flujo.

El sandbox vulnerable estaba destinado a preservar esa separación. Su fallo convierte un lenguaje de configuración en una posible superficie de ejecución. Esa es la inversión central detrás de la vulnerabilidad de GitLab AI Gateway: una función diseñada para gobernar acciones de agentes se convierte en una ruta que elude su propia capa de contención.

La inyección de plantillas también difiere de la inyección de prompts. La inyección de prompts manipula las instrucciones enviadas a un modelo, a menudo con el objetivo de redirigir su comportamiento o revelar datos contextuales. La inyección de plantillas ataca al software que construye o renderiza esos prompts. Cuando el motor de plantillas expone objetos o funciones inseguras, el resultado puede incluir ejecución del lado del servidor independientemente de cómo responda el modelo.

CWE-1336 formaliza esta clase de fallo. La debilidad del motor de plantillas aparece cuando el software no neutraliza elementos que un motor de plantillas trata como sintaxis ejecutable. La respuesta más segura no es otra instrucción conductual para el modelo. Es una corrección de software que impide que los datos controlados por un atacante se conviertan en contenido ejecutable de plantilla.

Esta diferencia debe orientar la revisión del incidente. Los equipos deben inspeccionar permisos de aplicación, historiales de configuración, registros del gateway, actividad de contenedores y credenciales posteriores. Revisar únicamente las transcripciones de conversaciones de IA pasaría por alto la actividad que ocurre en el proceso del gateway o en su entorno de ejecución.

Un gateway suele ocupar una posición de integración privilegiada incluso cuando no se ejecuta como root. Puede comunicarse con la instancia de GitLab, servidores de modelos, sistemas de observabilidad o servicios de red internos. Los operadores deben mapear estas conexiones en lugar de asumir que la ejecución de comandos en un contenedor equivale automáticamente a comprometer toda la infraestructura.

La contenerización puede reducir el impacto cuando está bien configurada, pero no elimina el incidente. Un contenedor comprometido aún puede exponer secretos montados, tokens de servicio, sistemas accesibles por red o datos gestionados por el proceso. Los permisos excesivos, los montajes escribibles y las rutas de red amplias aumentan ese radio de impacto.

Por tanto, la puntuación de 9,9 describe una evaluación estandarizada del peor caso, no prueba de que todos los entornos afectados hayan sufrido el daño máximo. Los administradores deben combinar esa puntuación con su arquitectura de despliegue real. La conclusión correcta es una investigación y corrección urgentes, no la confirmación automática de una brecha.

El autohospedaje intercambia control de datos por responsabilidad de parcheo

La promesa de seguridad de un gateway autohospedado solo sigue siendo válida cuando los clientes pueden inventariar, aislar, actualizar y supervisar ese gateway como infraestructura crítica.

GitLab admite configuraciones de IA gestionadas, híbridas y totalmente autohospedadas. En la modalidad gestionada, GitLab opera el gateway y lo conecta con proveedores externos de modelos seleccionados. Un despliegue autohospedado sitúa el gateway y la ruta del modelo dentro de una infraestructura controlada por el cliente.

Esa arquitectura puede respaldar requisitos estrictos de privacidad, residencia de datos y aislamiento de red. La guía de autoalojamiento de GitLab señala que las organizaciones pueden operar su propia puerta de enlace y sus propios modelos para mantener un control total sobre la infraestructura de IA. Una configuración completamente autoalojada también puede funcionar en una red con acceso limitado o nulo a Internet en general.

CVE-2026-90970 revela la otra cara de ese acuerdo. El cliente obtiene control sobre la ubicación y el flujo de datos, pero también asume el mantenimiento de la puerta de enlace desplegada. GitLab no puede actualizar de forma silenciosa un contenedor que se ejecuta dentro de un entorno controlado por el cliente.

Esa responsabilidad puede volverse poco clara porque una puerta de enlace de IA convive con infraestructura de desarrollo más conocida. Los equipos de plataforma pueden gestionar la aplicación de GitLab, mientras que los equipos de aprendizaje automático mantienen el servidor de modelos. Un grupo independiente puede ser responsable de la plataforma de contenedores o de los controles de red.

Si ningún equipo asume explícitamente la propiedad de la imagen de la puerta de enlace, su estado de parcheo puede quedar entre esos límites. Una puerta de enlace gestionada evita ese problema específico de coordinación porque el proveedor controla el despliegue. El autoalojamiento exige un proceso interno que trate la puerta de enlace como un servicio de producción independiente.

El inventario es el primer punto crítico. Las organizaciones deben saber si utilizan la puerta de enlace gestionada de GitLab, una puerta de enlace autoalojada o un modelo híbrido. Los despliegues híbridos requieren comprensión a nivel de funcionalidad, ya que algunas solicitudes pueden utilizar infraestructura del cliente mientras que otras usan servicios gestionados por GitLab.

El descubrimiento de versiones es el segundo punto crítico. Los operadores deben identificar cada instancia de puerta de enlace autoalojada, incluidos los sistemas de prueba de concepto y los entornos desconectados. Un despliegue aislado puede seguir siendo vulnerable a personas internas autenticadas o identidades comprometidas incluso si no puede recibir tráfico directo de Internet.

La aplicación de parches es el tercer punto crítico. Las instalaciones afectadas necesitan una versión corregida de la puerta de enlace, no solo una actualización de la aplicación visible de GitLab. Los equipos deben conservar evidencia del despliegue, registrar el digest de la imagen anterior y confirmar que las cargas de trabajo se reiniciaron con la versión prevista.

El cuarto punto crítico es el análisis de exposición. Los administradores deben identificar qué usuarios y cuentas de servicio tuvieron acceso a Duo Agent Platform durante el período vulnerable. También deben determinar quién podía crear o modificar flujos y si esas acciones generaron registros de auditoría utilizables.

El quinto es la revisión en tiempo de ejecución. Una investigación posterior al parche debe comparar el comportamiento de los procesos de la puerta de enlace con su línea base normal. Los procesos secundarios inesperados, intérpretes de comandos, cambios de archivos, nuevas conexiones salientes o reinicios inusuales de contenedores merecen ser examinados.

Los secretos requieren especial atención. La documentación de instalación de GitLab explica que la puerta de enlace utiliza JSON Web Tokens firmados para autenticar solicitudes. Los servicios autoalojados también reciben valores de configuración y claves a través de su entorno de ejecución. Estos mecanismos son necesarios para el funcionamiento normal, pero cualquier credencial accesible a un proceso comprometido puede requerir rotación.

La guía de instalación también describe AI Gateway y Duo Agent Platform como servicios separados con pares de claves de firma independientes. Esa separación ofrece a los defensores un marco útil para la revisión. Deben evaluar ambos servicios, su relación de confianza y las credenciales utilizadas entre ellos.

El diseño de red puede modificar sustancialmente las consecuencias. Una puerta de enlace que solo puede alcanzar un servidor de modelos y puntos de conexión de GitLab definidos de forma restrictiva presenta menos oportunidades que una con acceso amplio a través de redes internas. Las restricciones de salida, las identidades de carga de trabajo, los sistemas de archivos de solo lectura y los privilegios mínimos de contenedor siguen siendo controles relevantes.

Sin embargo, el aislamiento de red debe complementar el parcheo, no reemplazarlo. Un servicio interno vulnerable puede ser atacado desde otra cuenta o carga de trabajo interna comprometida. La segmentación limita el movimiento y el acceso a los datos, pero no corrige el procesamiento inseguro de plantillas.

Los operadores también deben considerar los datos que pasan por la puerta de enlace. El autoalojamiento suele elegirse precisamente porque los prompts pueden contener código fuente propietario, contexto de incidencias o instrucciones internas. Si se produjo una explotación, los investigadores deben determinar a qué información podía acceder la puerta de enlace, no solo qué archivos existían dentro de su contenedor.

Este trabajo pertenece a la misma categoría operativa que la protección de ejecutores de CI, repositorios de artefactos y gestores de secretos. Todos estos servicios traducen entradas controladas por desarrolladores en acciones automatizadas. Su utilidad proviene de una conectividad privilegiada, lo que también hace importante su aislamiento y su cadencia de actualización.

La lección no es que la infraestructura de IA gestionada sea siempre más segura. Los servicios gestionados concentran la responsabilidad del proveedor y reducen el trabajo de parcheo del cliente, pero los clientes aceptan distintas compensaciones en materia de confianza, residencia y dependencia. La lección es que el autoalojamiento cambia quién debe responder cuando aparece una falla crítica en la puerta de enlace.

Una falla anterior con puntuación 9.9 hace que esto sea más que un parche aislado

CVE-2026-90970 es el segundo problema de plantillas de GitLab AI Gateway documentado públicamente con una puntuación de 9.9 en 2026, lo que refuerza la necesidad de una revisión arquitectónica.

En febrero de 2026, GitLab solucionó CVE-2026-1868 en el componente Duo Workflow Service de AI Gateway. La asignación pública de CVE de GitLab describe una expansión insegura de plantillas de datos proporcionados por usuarios mediante definiciones de flujo de Duo Agent Platform especialmente elaboradas.

La vulnerabilidad anterior tenía el mismo vector CVSS 3.1 y una puntuación de gravedad de 9.9. Sus versiones corregidas incluían AI Gateway 18.6.2, 18.7.1 y 18.8.1. GitLab atribuyó el descubrimiento de esa falla a un miembro interno de su equipo.

Según el registro actual, la nueva vulnerabilidad afecta líneas de versiones posteriores que comienzan en la 18.1.6 y se extienden hasta la serie 19.4. Las descripciones públicas de ambos problemas implican definiciones o configuraciones de flujo elaboradas, manejo de plantillas, acceso autenticado de bajos privilegios y posible ejecución de comandos.

Esa similitud no demuestra que los parches hayan fallado de la misma manera. Los resúmenes públicos de vulnerabilidades son demasiado limitados para establecer si CVE-2026-90970 es una regresión, una corrección anterior incompleta o una ruta distinta de plantillas inseguras. Tratar esas posibilidades como confirmadas exageraría la evidencia.

Aun así, los defensores no deberían evaluar la divulgación de octubre de forma aislada. Dos hallazgos críticos en torno al mismo límite amplio de confianza indican que el procesamiento de configuraciones de flujo merece pruebas más profundas. Una actualización de versión de una sola línea puede cerrar la ruta divulgada mientras deja sin respuesta cuestiones de diseño más amplias.

El principal antagonista de esta historia es la promesa de gobernanza de la plataforma frente a la realidad de una superficie de configuración ejecutable. GitLab presenta los flujos agénticos como automatizaciones controladas que operan dentro de procesos de desarrollo establecidos. Esos controles pierden valor si los autores autorizados de flujos pueden llegar a comandos a nivel de puerta de enlace.

El problema no es exclusivo de la categoría de productos de GitLab. Las puertas de enlace de IA, los orquestadores de agentes y los motores de flujos de trabajo traducen entradas flexibles de usuarios en operaciones privilegiadas. Sus formatos de configuración pueden convertirse en lenguajes de programación incluso cuando las interfaces de producto los presentan como archivos declarativos.

Esa flexibilidad crea una compensación de seguridad recurrente. Los clientes desean agentes personalizables que puedan inspeccionar repositorios, llamar herramientas, responder a eventos y completar objetivos de varios pasos. Cada nueva herramienta, expresión, variable de plantilla o plugin amplía lo que la capa de orquestación debe interpretar de forma segura.

Un lenguaje de configuración estricto puede reducir el riesgo, pero limita la personalización del cliente. Un lenguaje flexible admite más flujos de trabajo, pero requiere aislamiento maduro, controles del analizador, límites de permisos y pruebas de seguridad. El riesgo aumenta cuando un único proceso tanto procesa plantillas no confiables como posee acceso valioso a la infraestructura.

Por ello, la defensa necesita varias capas independientes. El analizador debe tratar los valores no confiables como datos. El entorno de plantillas debe exponer el conjunto de objetos más reducido posible. La autorización debe limitar quién puede enviar flujos. El entorno de ejecución de la puerta de enlace debe tener acceso mínimo al sistema de archivos, la red y las credenciales.

La auditabilidad aporta otra capa. Los eventos de creación y modificación de flujos deben poder atribuirse a identidades humanas o de servicio específicas. Las organizaciones deberían poder conectar una configuración enviada con la actividad posterior de la puerta de enlace. Sin esa cadena, confirmar o descartar una explotación se vuelve mucho más difícil.

La vulnerabilidad anterior también cambia la forma en que los equipos deben abordar la verificación de actualizaciones. No basta con establecer que la imagen corregida más reciente se inició correctamente. Los operadores deben confirmar que réplicas antiguas, imágenes en caché, clústeres de prueba y entornos de recuperación ante desastres no conservan versiones afectadas.

Los entornos desconectados pueden ser especialmente engañosos. La falta de acceso general a Internet reduce algunas amenazas externas, pero puede ralentizar la entrega de avisos de seguridad y parches. Un usuario autorizado dentro de ese entorno aún puede acceder a la funcionalidad de la aplicación requerida por la vulnerabilidad.

Una evaluación escéptica también debe reconocer lo que sigue siendo desconocido. Los registros públicos aún no proporcionan una prueba de concepto, una ruta de llamadas detallada ni telemetría confirmada de explotación. Tampoco identifican un conjunto universal de indicadores posteriores a la explotación para cada despliegue.

Esas lagunas limitan las afirmaciones confiadas sobre ataques observados, pero no debilitan la recomendación de parchear. Una falla de ejecución de comandos confirmada por el proveedor con una puntuación de 9.9 presenta suficiente riesgo como para justificar una corrección inmediata. Esperar evidencia pública de explotación intercambiaría incertidumbre por una exposición prevenible.

La cuestión más sólida a largo plazo es si el procesamiento de plantillas sigue siendo necesario en su contexto actual de confianza. GitLab puede reducir el riesgo futuro publicando más detalles técnicos después de que los clientes hayan tenido tiempo de aplicar parches. La información sobre la causa raíz ayudaría a los operadores a entender qué límites fallaron y qué controles compensatorios importan más.

Mientras tanto, los clientes deben tratar los flujos de agentes personalizados como código. Merecen revisión, propiedad, control de cambios y pruebas comparables a la configuración de CI. Una interfaz visual o declarativa no hace que un flujo de trabajo sea no ejecutable cuando la plataforma convierte su contenido en acciones.

Qué deberían vigilar los defensores a continuación

La próxima evaluación debería depender de tres señales: adopción de parches, divulgación de la causa raíz por parte de GitLab y evidencia relativa a la explotación en el mundo real.

La primera señal es si los operadores autoalojados alcanzan rápidamente las versiones corregidas de AI Gateway. GitLab controla su servicio alojado, pero no puede medir cada despliegue de cliente dentro de infraestructura privada. Los equipos de seguridad deben establecer su propia evidencia de finalización en lugar de asumir que los informes habituales de actualización de software incluyen la puerta de enlace.

Esa evidencia debe identificar el despliegue, la versión anterior, la imagen de reemplazo, la hora de reinicio y el resultado de la validación. También debe cubrir sistemas de desarrollo y recuperación ante desastres. Si las organizaciones tienen dificultades para producir este inventario, el incidente revela un problema de propiedad más allá de la propia vulnerabilidad.

Una adopción rápida de parches reforzaría la idea de que las empresas pueden gestionar componentes de IA autoalojados como infraestructura de producción convencional. Una adopción lenta o no medida debilitaría el argumento de control detrás del despliegue privado. La localización de datos ofrece una protección limitada cuando el middleware crítico permanece sin seguimiento.

La segunda señal es una explicación técnica más completa por parte de GitLab. Los defensores necesitan saber si CVE-2026-90970 representa una nueva ruta de plantillas, una regresión o una mitigación incompleta de la falla anterior. Esa distinción afecta la confianza en la arquitectura circundante y en la estrategia de pruebas.

Una divulgación útil explicaría el componente vulnerable, el límite de privilegios afectado y los cambios de contención, sin aportar detalles innecesarios para la explotación. También aclararía si los servicios independientes de Agent Platform y AI Gateway requieren medidas distintas tras el incidente.

La confirmación de una causa raíz diferente sugeriría que el refuerzo generalizado de las plantillas está funcionando ante múltiples hallazgos. La evidencia de una elusión de una mitigación anterior plantearía preguntas más incisivas sobre si el límite de seguridad inicial se diseñó de forma integral.

La tercera señal es evidencia creíble sobre la explotación. Deben vigilarse GitLab y las agencias de seguridad en busca de indicadores de compromiso, listados de vulnerabilidades explotadas conocidas o directrices de respuesta revisadas. Los informes independientes de incidentes también serían relevantes si incluyen telemetría verificable.

Hasta que aparezca esa evidencia, los artículos no deberían describir CVE-2026-90970 como una vulnerabilidad explotada activamente. La ausencia de confirmación pública no equivale a confirmar que no se haya producido explotación. Las organizaciones deben tomar decisiones de respuesta basándose en la exposición y el impacto, no solo en los titulares.

Los equipos pueden comenzar con cuatro preguntas prácticas. ¿Operamos algún AI Gateway autohospedado? ¿Todas las instancias ejecutan las versiones 19.2.4, 19.3.2, 19.4.1 o posteriores? ¿Quién podía modificar los flujos de agentes Duo durante el período afectado? ¿A qué sistemas y secretos podía acceder el proceso del gateway?

Las respuestas deben conservarse junto con los registros de incidentes, el historial de configuración y los registros pertinentes. Los equipos que necesiten vincular notas de despliegue, decisiones de propiedad y evidencias de revisión pueden mantener una base de conocimientos con capacidad de búsqueda. La documentación no corregirá la vulnerabilidad, pero la evidencia fragmentada puede retrasar la contención y las auditorías posteriores.

En última instancia, la vulnerabilidad de GitLab AI Gateway pone a prueba si la infraestructura de agentes recibe la misma disciplina operativa que los sistemas de CI y otros servicios de ejecución de código. Aplique el parche al gateway afectado, verifique la imagen en ejecución, revise los cambios autorizados en los flujos, rote las credenciales expuestas cuando la evidencia lo justifique y reduzca los privilegios del gateway.

Después, plantee la pregunta más difícil: si otra configuración de agente cruza un límite de confianza el próximo mes, ¿podrá su equipo identificar al responsable, las versiones afectadas, los activos accesibles y la ruta de respuesta sin tener que reconstruir el inventario durante el incidente?