Vulnerabilidade no GitLab AI Gateway transforma acesso autorizado ao Duo em um risco crítico de RCE

O GitLab corrigiu uma vulnerabilidade no GitLab AI Gateway, classificada em 9,9, que pode transformar o acesso autorizado à Duo Agent Platform em execução de comandos em um gateway auto-hospedado. A falha, identificada como CVE-2026-90970, ultrapassa uma fronteira que o produto deveria impor. Uma configuração de fluxo cuidadosamente elaborada pode escapar da sandbox de templates de prompts e executar comandos arbitrários no gateway.

Essa qualificação importa. Não se trata de um comprometimento por zero-click relatado em todos os servidores GitLab, nem ela concede acesso imediato a um usuário anônimo da internet. A exploração exige autenticação e acesso à Duo Agent Platform. No entanto, a avaliação de severidade do GitLab reflete o que acontece após essas condições serem atendidas: exploração de rede de baixa complexidade, sem interação adicional do usuário e com consequências potencialmente graves para confidencialidade, integridade e disponibilidade.

O incidente cria um conflito direto entre controle e responsabilidade. Organizações hospedam infraestrutura de IA por conta própria para manter código, prompts e tráfego de modelos dentro de limites confiáveis. Ainda assim, a auto-hospedagem também torna essas organizações responsáveis por atualizar o serviço que processa esse material sensível. Gateways hospedados pelo GitLab já receberam correção, enquanto operadores de gateways auto-hospedados afetados precisam concluir suas próprias atualizações.

O que mudou com a vulnerabilidade no GitLab AI Gateway

A CVE-2026-90970 transforma a permissão para configurar um fluxo de trabalho de IA em um possível caminho para comandos do sistema operacional.

O GitLab divulgou o problema em 2 de outubro de 2026. De acordo com o registro público da vulnerabilidade, as versões afetadas incluem versões do AI Gateway de 18.1.6 até versões anteriores à 19.2.4. A ramificação 19.3 é afetada antes da 19.3.2, enquanto a ramificação 19.4 é afetada antes da 19.4.1.

Esses limites de versão diferem do histórico de lançamentos da aplicação principal do GitLab. Portanto, administradores devem verificar a própria imagem ou implantação do AI Gateway. Conferir apenas a versão visível da aplicação GitLab pode criar uma falsa sensação de segurança quando o gateway segue um ciclo de implantação separado.

As versões corrigidas são 19.2.4, 19.3.2 e 19.4.1. Operadores devem migrar para a versão corrigida apropriada ou uma versão posterior com suporte. Gateways hospedados pelo GitLab já receberam a correção; portanto, GitLab.com e clientes que usam o gateway gerenciado pelo GitLab não enfrentam a mesma tarefa de aplicação de patches.

O caminho vulnerável começa com uma configuração de fluxo especialmente elaborada. Um fluxo define uma sequência agentiva que pode combinar prompts, ferramentas, decisões e ações. A GitLab Duo Agent Platform usa essas configurações para executar tarefas de desenvolvimento de software em várias etapas, em vez de responder a um único prompt isolado.

Templates de prompts convertem a configuração e os dados de execução de um fluxo em instruções que um modelo de IA consegue processar. Uma sandbox de templates é o ambiente restrito destinado a impedir que o conteúdo do template alcance capacidades inseguras da aplicação ou do sistema operacional. A CVE-2026-90970 envolve neutralização inadequada dentro dessa fronteira.

A fraqueza é categorizada como CWE-1336, ou neutralização inadequada de elementos especiais usados em um mecanismo de templates. Na prática, uma sintaxe controlada pelo atacante pode ser interpretada como comportamento executável do template, em vez de dados inertes. O resultado perigoso exato depende da aplicação ao redor, das funções disponíveis e dos privilégios do processo.

Para essa falha, o GitLab afirma que o resultado pode ser a execução arbitrária de comandos no AI Gateway. Esse resultado é mais grave do que manipular uma resposta de IA. Ele significa que a vulnerabilidade vai além da saída do modelo e alcança o ambiente de execução convencional que hospeda o gateway.

A distinção entre o AI Gateway e um grande modelo de linguagem é importante. O gateway é um serviço de aplicação independente, posicionado entre recursos do GitLab e modelos de IA. A documentação do gateway do GitLab afirma que o serviço fornece acesso a recursos nativos de IA do GitLab Duo. Ele processa a lógica da aplicação e as solicitações relacionadas ao modelo, em vez de funcionar como o próprio modelo.

Consequentemente, a vulnerabilidade não é evidência de que um modelo descobriu de forma independente uma fuga ou ignorou uma instrução comportamental de segurança. O mecanismo relatado é uma vulnerabilidade de software no processamento de templates. Sua entrada, por acaso, chega por uma superfície de configuração agentiva.

Esse fato mantém o incidente em uma categoria de segurança conhecida, mas o contexto eleva os riscos. Gateways de IA podem lidar com contexto derivado de código-fonte, instruções de fluxo de trabalho, material de autenticação e conexões com back-ends de modelos. Uma falha de execução de comandos nesse ponto de junção pode expor mais do que um prompt malformado ou uma resposta pouco confiável.

O GitLab não descreveu publicamente exploração disseminada da CVE-2026-90970. O registro disponível também não estabelece que invasores tenham usado a vulnerabilidade contra ambientes de produção. Administradores não devem interpretar essa lacuna de verificação como prova de segurança, especialmente depois que a divulgação oferece a potenciais invasores um alvo mais claro.

A mudança imediata é, portanto, operacional. Um AI Gateway auto-hospedado antes tratado como um componente interno controlado agora exige verificação urgente de versão, aplicação de patches e revisão pós-atualização. Seu risco não pode ser inferido apenas pelo fato de a interface principal do GitLab ser pública.

Por que uma fuga de sandbox autenticada recebe nota 9,9

A vulnerabilidade é crítica porque seus pré-requisitos limitam quem pode atacar, enquanto seu impacto potencial continua amplo quando a sandbox falha.

O GitLab atribuiu à CVE-2026-90970 uma pontuação base CVSS 3.1 de 9,9. O vetor publicado é AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Cada elemento explica por que uma falha autenticada ainda pode ficar próxima ao topo da escala de severidade.

O vetor de ataque pela rede significa que um possível invasor não precisa de acesso local ao shell do host do gateway. O serviço relevante pode receber a configuração maliciosa por meio de funcionalidades da aplicação acessíveis pela rede. Acessível pela rede não significa necessariamente exposto a toda a internet pública, mas amplia o possível caminho de ataque para além do acesso físico ou local.

Baixa complexidade de ataque indica que a exploração não depende de uma condição de corrida restrita ou de um estado de implantação incomum. São exigidos poucos privilégios, e não nenhum privilégio. O usuário deve estar autenticado e ter acesso à Duo Agent Platform.

Ausência de interação do usuário significa que outra pessoa não precisa abrir um arquivo, aprovar uma caixa de diálogo ou visitar um link malicioso depois que a configuração alcança o caminho vulnerável. Essa característica importa em ambientes colaborativos de desenvolvimento, nos quais automações confiáveis frequentemente processam configurações enviadas sem uma segunda ação humana.

O componente de escopo alterado é especialmente significativo. Ele indica que a exploração pode afetar recursos além da autoridade de segurança representada pelo componente vulnerável original. Aqui, a entrada do template começa dentro de um fluxo de trabalho agentivo autorizado, mas pode cruzar para o ambiente de execução de comandos do gateway.

As três métricas finais registram alto impacto potencial para confidencialidade, integridade e disponibilidade. A execução de comandos pode, em teoria, permitir a leitura de informações acessíveis, a modificação de recursos do gateway ou a interrupção do serviço. O dano real ainda depende da arquitetura de implantação, das permissões do processo, do alcance da rede e das credenciais disponíveis.

Esse contexto evita duas interpretações enganosas. Chamar a vulnerabilidade de “autenticada” não deve ser usado para descartá-la como um problema comum no nível da conta. Chamá-la de “execução remota de código” não deve implicar que todo visitante anônimo possa comprometer imediatamente um ambiente GitLab.

O invasor relevante pode já ser um usuário válido. Também pode ser alguém que controla uma conta comprometida, um token roubado ou uma identidade de automação com privilégios excessivos. Os limites de segurança devem continuar funcionando após a autenticação, porque o acesso legítimo raramente equivale a autoridade ilimitada sobre a infraestrutura.

Sistemas agentivos tornam essa distinção mais urgente. Eles aceitam instruções estruturadas e podem executar sequências de ações em serviços de desenvolvimento. Um usuário autorizado a definir um fluxo pode precisar de amplas capacidades na aplicação, mas esse usuário não deve herdar os privilégios do sistema operacional do serviço que interpreta o fluxo.

A sandbox vulnerável deveria preservar essa separação. Sua falha transforma uma linguagem de configuração em uma possível superfície de execução. Essa é a inversão central por trás da vulnerabilidade no GitLab AI Gateway: um recurso concebido para controlar ações de agentes torna-se uma rota para contornar sua própria camada de contenção.

A injeção de templates também difere da injeção de prompts. A injeção de prompts manipula instruções enviadas a um modelo, frequentemente tentando redirecionar o comportamento do modelo ou revelar dados contextuais. A injeção de templates ataca o software que constrói ou renderiza esses prompts. Quando o mecanismo de templates expõe objetos ou funções inseguras, o resultado pode incluir execução no lado do servidor, independentemente de como o modelo responde.

A CWE-1336 formaliza essa classe de falha. A fraqueza em mecanismos de templates surge quando o software não neutraliza elementos que um mecanismo de templates trata como sintaxe executável. A resposta mais segura não é outra instrução comportamental para o modelo. É uma correção de software que impede que dados controlados por atacantes se tornem conteúdo de template executável.

Essa diferença deve orientar a revisão do incidente. As equipes precisam inspecionar permissões da aplicação, históricos de configuração, logs do gateway, atividade de contêineres e credenciais posteriores. Revisar apenas transcrições de conversas de IA deixaria passar atividades que ocorrem no processo do gateway ou em seu ambiente de execução circundante.

Um gateway normalmente ocupa uma posição privilegiada de integração, mesmo quando não é executado como root. Ele pode se comunicar com a instância do GitLab, servidores de modelos, sistemas de observabilidade ou serviços internos de rede. Operadores devem mapear essas conexões em vez de presumir que a execução de comandos em um contêiner equivale automaticamente ao comprometimento total da infraestrutura.

A conteinerização pode reduzir o impacto quando bem configurada, mas não elimina o incidente. Um contêiner comprometido ainda pode expor segredos montados, tokens de serviço, sistemas acessíveis pela rede ou dados processados pelo processo. Permissões excessivas, montagens graváveis e rotas de rede amplas ampliam esse raio de impacto.

A nota 9,9, portanto, descreve uma avaliação padronizada de pior caso, não uma prova de que todo ambiente afetado sofreu o dano máximo. Administradores devem combinar essa pontuação com sua arquitetura de implantação real. A conclusão correta é investigação e correção urgentes, não confirmação automática de uma violação.

A auto-hospedagem troca controle de dados pela responsabilidade de aplicar patches

A promessa de segurança de um gateway auto-hospedado permanece válida somente quando os clientes conseguem inventariar, isolar, atualizar e monitorar esse gateway como infraestrutura crítica.

O GitLab oferece configurações de IA gerenciadas, híbridas e totalmente auto-hospedadas. No modelo gerenciado, o GitLab opera o gateway e o conecta a provedores externos de modelos selecionados. Uma implantação auto-hospedada coloca o gateway e o caminho do modelo dentro de uma infraestrutura controlada pelo cliente.

Essa arquitetura pode atender a requisitos rigorosos de privacidade, residência de dados e isolamento de rede. O guia de auto-hospedagem do GitLab afirma que as organizações podem operar seu próprio gateway e seus próprios modelos para ter controle total sobre a infraestrutura de IA. Uma configuração totalmente auto-hospedada também pode funcionar em uma rede com acesso geral à internet limitado ou inexistente.

A CVE-2026-90970 expõe a outra metade desse acordo. O cliente ganha controle sobre localização e fluxo de dados, mas também assume a manutenção do gateway implantado. O GitLab não pode atualizar silenciosamente um contêiner em execução dentro de um ambiente controlado pelo cliente.

Essa responsabilidade pode se tornar pouco clara porque um gateway de IA fica ao lado de infraestruturas de desenvolvimento mais conhecidas. As equipes de plataforma podem administrar o aplicativo GitLab, enquanto as equipes de aprendizado de máquina mantêm o servidor de modelos. Um grupo separado pode ser responsável pela plataforma de contêineres ou pelos controles de rede.

Se nenhuma equipe assumir explicitamente a responsabilidade pela imagem do gateway, seu estado de correção pode ficar entre essas fronteiras. Um gateway gerenciado evita esse problema específico de coordenação porque o fornecedor controla a implantação. A auto-hospedagem exige um processo interno que trate o gateway como um serviço de produção distinto.

O inventário é o primeiro ponto de pressão. As organizações precisam saber se usam o gateway gerenciado do GitLab, um gateway auto-hospedado ou uma configuração híbrida. Implantações híbridas exigem compreensão em nível de recurso, pois algumas solicitações podem usar a infraestrutura do cliente, enquanto outras usam serviços gerenciados pelo GitLab.

A descoberta de versões é o segundo ponto de pressão. Os operadores devem identificar todas as instâncias de gateway auto-hospedadas, incluindo sistemas de prova de conceito e ambientes desconectados. Uma implantação isolada ainda pode ser vulnerável a pessoas internas autenticadas ou identidades comprometidas, mesmo quando não consegue receber tráfego direto da internet.

A aplicação de correções é o terceiro ponto de pressão. Instalações afetadas precisam de uma versão corrigida do gateway, não apenas de uma atualização do aplicativo GitLab visível. As equipes devem preservar evidências da implantação, registrar o digest da imagem anterior e confirmar que as cargas de trabalho foram reiniciadas com a versão pretendida.

O quarto ponto de pressão é a análise de exposição. Os administradores devem identificar quais usuários e contas de serviço tinham acesso ao Duo Agent Platform durante o período vulnerável. Também devem determinar quem podia criar ou modificar fluxos e se essas ações geraram registros de auditoria utilizáveis.

O quinto é a revisão em tempo de execução. Uma investigação após a correção deve comparar o comportamento dos processos do gateway com sua linha de base normal. Processos-filhos inesperados, interpretadores de comandos, alterações de arquivos, novas conexões de saída ou reinicializações incomuns de contêineres merecem análise.

Os segredos exigem atenção especial. A documentação de instalação do GitLab explica que o gateway usa JSON Web Tokens assinados para autenticar solicitações. Serviços auto-hospedados também recebem valores de configuração e chaves por meio de seu ambiente de execução. Esses mecanismos são necessários para a operação normal, mas qualquer credencial acessível a um processo comprometido pode exigir rotação.

A orientação de instalação também descreve o AI Gateway e o Duo Agent Platform como serviços separados, com pares de chaves de assinatura distintos. Essa separação oferece aos defensores uma estrutura útil para revisão. Eles devem avaliar ambos os serviços, sua relação de confiança e as credenciais usadas entre eles.

O desenho da rede pode alterar substancialmente as consequências. Um gateway que só consegue alcançar um servidor de modelos e endpoints do GitLab estritamente definidos apresenta uma oportunidade menor do que um com amplo acesso por redes internas. Restrições de saída, identidades de carga de trabalho, sistemas de arquivos somente leitura e privilégios mínimos de contêiner continuam sendo controles relevantes.

No entanto, o isolamento de rede deve complementar a aplicação de correções, e não substituí-la. Um serviço interno vulnerável pode ser atacado a partir de outra conta ou carga de trabalho interna comprometida. A segmentação limita a movimentação e o acesso a dados, mas não corrige o processamento inseguro de modelos.

Os operadores também devem considerar os dados que passam pelo gateway. A auto-hospedagem costuma ser escolhida justamente porque os prompts podem conter código-fonte proprietário, contexto de issues ou instruções internas. Se a exploração ocorreu, os investigadores precisam determinar quais informações o gateway poderia acessar, e não apenas quais arquivos existiam dentro de seu contêiner.

Esse trabalho pertence à mesma categoria operacional da proteção de runners de CI, repositórios de artefatos e gerenciadores de segredos. Todos esses serviços traduzem entradas controladas por desenvolvedores em ações automatizadas. Sua utilidade decorre da conectividade privilegiada, que também torna importantes seu isolamento e sua cadência de atualização.

A lição não é que a infraestrutura de IA gerenciada seja sempre mais segura. Serviços gerenciados concentram a responsabilidade do fornecedor e reduzem o trabalho de correção do cliente, mas os clientes aceitam diferentes concessões de confiança, residência e dependência. A lição é que a auto-hospedagem muda quem precisa responder quando surge uma falha crítica no gateway.

Uma falha anterior com pontuação 9,9 mostra que isso é mais do que uma correção isolada

A CVE-2026-90970 é o segundo problema de modelo do GitLab AI Gateway documentado publicamente em 2026 com classificação 9,9, reforçando a necessidade de uma revisão arquitetural.

Em fevereiro de 2026, o GitLab corrigiu a CVE-2026-1868 no componente Duo Workflow Service do AI Gateway. A atribuição pública de CVE do GitLab descreve a expansão insegura de modelos de dados fornecidos por usuários por meio de definições de fluxo elaboradas do Duo Agent Platform.

A vulnerabilidade anterior tinha o mesmo vetor CVSS 3.1 e pontuação de gravidade 9,9. Suas versões corrigidas incluíam as versões 18.6.2, 18.7.1 e 18.8.1 do AI Gateway. O GitLab creditou a descoberta dessa falha a um integrante interno da equipe.

A nova vulnerabilidade afeta linhas de lançamento posteriores, começando na versão 18.1.6 e se estendendo à série 19.4, de acordo com o registro atual. As descrições públicas de ambos os problemas envolvem definições ou configurações de fluxo elaboradas, manipulação de modelos, acesso autenticado com poucos privilégios e possível execução de comandos.

Essa semelhança não prova que as correções falharam da mesma forma. Os resumos públicos de vulnerabilidades são limitados demais para estabelecer se a CVE-2026-90970 é uma regressão, uma correção anterior incompleta ou um caminho distinto de modelo inseguro. Tratar essas possibilidades como confirmadas exageraria as evidências.

Ainda assim, os defensores não devem avaliar a divulgação de outubro isoladamente. Duas descobertas críticas em torno da mesma fronteira ampla de confiança indicam que o processamento de configuração de fluxos merece testes mais profundos. Uma atualização de versão com uma única linha pode fechar o caminho divulgado, deixando questões mais amplas de desenho sem resposta.

O principal antagonismo desta história é a promessa de governança da plataforma frente à realidade de uma superfície de configuração executável. O GitLab posiciona os fluxos agênticos como automações controladas que operam dentro de processos de desenvolvimento estabelecidos. Esses controles perdem valor se autores de fluxos autorizados puderem avançar para comandos no nível do gateway.

O problema não é exclusivo da categoria de produto do GitLab. Gateways de IA, orquestradores de agentes e mecanismos de fluxo de trabalho traduzem entradas flexíveis de usuários em operações privilegiadas. Seus formatos de configuração podem se tornar linguagens de programação mesmo quando as interfaces dos produtos os apresentam como arquivos declarativos.

Essa flexibilidade cria uma concessão de segurança recorrente. Os clientes querem agentes personalizáveis que possam inspecionar repositórios, chamar ferramentas, responder a eventos e concluir objetivos de múltiplas etapas. Cada nova ferramenta, expressão, variável de modelo ou plugin amplia o que a camada de orquestração precisa interpretar com segurança.

Uma linguagem de configuração rígida pode reduzir riscos, mas limita a personalização dos clientes. Uma linguagem flexível oferece suporte a mais fluxos de trabalho, mas exige sandboxing maduro, controles de parser, fronteiras de permissão e testes de segurança. O risco aumenta quando um único processo tanto renderiza modelos não confiáveis quanto detém acesso valioso à infraestrutura.

A defesa, portanto, precisa de várias camadas independentes. O parser deve tratar valores não confiáveis como dados. O ambiente de modelos deve expor o menor conjunto possível de objetos. A autorização deve limitar quem pode enviar fluxos. O ambiente de execução do gateway deve ter acesso mínimo a sistema de arquivos, rede e credenciais.

A auditabilidade fornece outra camada. Eventos de criação e modificação de fluxos devem ser atribuíveis a identidades humanas ou de serviço específicas. As organizações devem conseguir conectar uma configuração enviada à atividade subsequente do gateway. Sem essa cadeia, confirmar ou descartar uma exploração se torna muito mais difícil.

A vulnerabilidade anterior também altera como as equipes devem lidar com a verificação de atualizações. Não basta estabelecer que a imagem corrigida mais recente iniciou com sucesso. Os operadores devem confirmar que réplicas antigas, imagens em cache, clusters de teste e ambientes de recuperação de desastre não retêm versões afetadas.

Ambientes desconectados podem ser especialmente enganosos. A falta de acesso geral à internet reduz algumas ameaças externas, mas pode atrasar a entrega de avisos e correções de segurança. Um usuário autorizado dentro desse ambiente ainda pode alcançar a funcionalidade do aplicativo exigida pela vulnerabilidade.

Uma avaliação cética também deve reconhecer o que permanece desconhecido. Os registros públicos ainda não fornecem uma prova de conceito, um caminho de chamada detalhado ou telemetria de exploração confirmada. Eles não identificam um conjunto universal de indicadores pós-exploração para todas as implantações.

Essas lacunas restringem afirmações confiantes sobre ataques observados, mas não enfraquecem a recomendação de correção. Uma falha de execução de comandos confirmada pelo fornecedor, com pontuação 9,9, apresenta risco suficiente para justificar a correção imediata. Esperar por evidências públicas de exploração trocaria incerteza por exposição evitável.

A questão mais forte de longo prazo é se o processamento de modelos continua necessário em seu atual contexto de confiança. O GitLab pode reduzir riscos futuros ao publicar mais detalhes técnicos depois que os clientes tiverem tempo para aplicar correções. Informações sobre a causa raiz ajudariam os operadores a entender quais fronteiras falharam e quais controles compensatórios mais importam.

Enquanto isso, os clientes devem tratar fluxos de agentes personalizados como código. Eles merecem revisão, responsabilidade, controle de mudanças e testes comparáveis à configuração de CI. Uma interface visual ou declarativa não torna um fluxo de trabalho não executável quando a plataforma transforma seu conteúdo em ações.

O que os defensores devem acompanhar a seguir

A próxima avaliação deve depender de três sinais: adoção de correções, divulgação da causa raiz pelo GitLab e evidências sobre exploração no mundo real.

O primeiro sinal é se os operadores auto-hospedados alcançam rapidamente versões corrigidas do AI Gateway. O GitLab controla seu serviço hospedado, mas não consegue medir cada implantação de cliente dentro de infraestrutura privada. As equipes de segurança devem estabelecer suas próprias evidências de conclusão, em vez de presumir que os relatórios normais de atualização de software incluem o gateway.

Essas evidências devem identificar a implantação, a versão anterior, a imagem substituta, o horário da reinicialização e o resultado da validação. Também devem abranger sistemas de desenvolvimento e recuperação de desastre. Se as organizações tiverem dificuldade para produzir esse inventário, o incidente revela um problema de responsabilidade que vai além da própria vulnerabilidade.

A adoção rápida de correções fortaleceria a tese de que as empresas podem gerenciar componentes de IA auto-hospedados como infraestrutura de produção convencional. A adoção lenta ou não medida enfraqueceria o argumento de controle por trás da implantação privada. A localidade dos dados oferece proteção limitada quando o middleware crítico permanece sem rastreamento.

O segundo sinal é uma explicação técnica mais completa do GitLab. Os defensores precisam saber se a CVE-2026-90970 representa um novo caminho de modelo, uma regressão ou uma mitigação incompleta da falha anterior. Essa distinção afeta a confiança na arquitetura ao redor e na estratégia de testes.

Uma divulgação útil explicaria o componente vulnerável, o limite de privilégios afetado e as mudanças de contenção, sem fornecer detalhes desnecessários de exploração. Também esclareceria se os serviços separados Agent Platform e AI Gateway exigem ações pós-incidente distintas.

A confirmação de uma causa raiz distinta sugeriria que o reforço amplo dos modelos está funcionando diante de múltiplas descobertas. Evidências de um desvio em torno de uma mitigação anterior levantariam questões mais incisivas sobre se o limite de segurança inicial foi projetado de forma abrangente.

O terceiro sinal são evidências confiáveis de exploração. GitLab e as agências de segurança devem ser acompanhados em busca de indicadores de comprometimento, listas de vulnerabilidades conhecidamente exploradas ou orientações de resposta revisadas. Relatos independentes de incidentes também seriam relevantes se incluíssem telemetria verificável.

Até que essas evidências surjam, os artigos não devem descrever a CVE-2026-90970 como explorada ativamente. A ausência de confirmação pública não equivale à confirmação de que nenhuma exploração ocorreu. As organizações devem tomar decisões de resposta com base na exposição e no impacto, e não apenas nas manchetes.

As equipes podem começar com quatro perguntas práticas. Operamos algum AI Gateway auto-hospedado? Todas as instâncias executam a versão 19.2.4, 19.3.2, 19.4.1 ou posterior? Quem poderia modificar os fluxos de agentes Duo durante o período afetado? A quais sistemas e segredos o processo do gateway poderia ter acesso?

As respostas devem ser preservadas junto aos registros de incidentes, ao histórico de configurações e aos logs relevantes. As equipes que precisam conectar notas de implantação, decisões de responsabilidade e evidências de revisão podem manter uma base de conhecimento pesquisável. A documentação não corrigirá a vulnerabilidade, mas evidências fragmentadas podem atrasar a contenção e auditorias posteriores.

A vulnerabilidade do GitLab AI Gateway, em última análise, testa se a infraestrutura de agentes recebe a mesma disciplina operacional aplicada aos sistemas de CI e a outros serviços de execução de código. Aplique o patch no gateway afetado, verifique a imagem em execução, revise as alterações autorizadas nos fluxos, rotacione credenciais expostas quando as evidências justificarem e reduza os privilégios do gateway.

Em seguida, faça a pergunta mais difícil: se outra configuração de agente cruzar um limite de confiança no próximo mês, sua equipe conseguirá identificar o responsável, as versões afetadas, os ativos acessíveis e o caminho de resposta sem reconstruir o inventário durante o incidente?