GitLab corrige CVE-2026-90970 crítico em AI Gateway; adesivos para self-hosted

GitLab publicou um aviso de segurança que descreve uma vulnerabilidade crítica em seu serviço AI Gateway que, em determinadas condições, permitia a um usuário autenticado com acesso à plataforma Duo Agent escapar do "sandbox" de modelos de prompts e executar comandos arbitrários no próprio gateway. A falha foi registada como CVE-2026-90970, recebeu uma pontuação CVSS de 9,9/10 e GitLab publicou a correção em 2 de outubro. As versões que contêm a solução são 19.2.4, 19.3.2 e 19.4.1 do componente AI Gateway.

Fatos confirmados: GitLab descreve o problema como uma fraqueza no modelo de prompts de um “custom flow” –flujos personalizados criados na Duo Agent Platform para automatizar tarefas – que poderia permitir a “escape” do ambiente seguro e derivar em execução de comandos na máquina que executa o gateway. GitLab opera gateways administrados para clientes em GitLab.com e GitLab Dedicated e afirma ter já mitigado o problema em seus gateways geridos; portanto, Apenas as organizações que alojam o seu próprio AI Gateway (self-hosted) devem aplicar o adesivo. O aviso identifica as versões fixas acima indicadas e não lista nenhuma mitigação alternativa nem uma forma incorporada para verificar se um gateway foi atacado antes de o actualizar.

Contexto técnico e alcance: o AI Gateway é o componente que conecta uma instância de GitLab com modelos de IA externos e, em implantaçãos self-hosted, instala-se como uma imagem Docker ou mediante Helm. Esse gateway armazena chaves de assinatura para JSON Web Tokens (JWT) e mantém conexões com o GitLab interno e fornecedores de modelos — portanto, a afectação potencial não é apenas o contentor do gateway, mas também a credenciais que facilitam autenticação e autorização no ambiente. GitLab qualifica o problema como da mesma classe que uma vulnerabilidade prévia em fevereiro (CVE-2026-1868) —ambas relacionadas a fraquezas no motor de modelos, classe CWE-1336—, o que indica um padrão em como os modelos de fluxo podem ser manipulados para quebrar limites de execução.

O que sabemos e o que não: confirmado é que um usuário autenticado com acesso a Duo Agent Platform era a via de ataque descrita; no entanto, o aviso não detalha os requisitos exatos (por exemplo, que papel de usuário concreto era necessário ou quais condições de configuração do gateway foram exploradas). Também não foi publicado um teste de conceito público, e a entrada do CVE inclui uma avaliação da CISA que enumera a exploração como “none” no seu campo de exploração conhecido, sugerindo que não há confirmação pública de ataques no panorama geral. Mesmo assim, a natureza da vulnerabilidade – ajecução de comandos em um componente que guarda chaves sensíveis – converte o risco a sério e com consequências potencialmente graves se fosse explorada em ambientes produtivos.

Conseqüências reais e risco para organizações: se um atacante conseguir executar código em um gateway comprometido, pode tentar exfiltrar ou rodar as chaves JWT, interceptar ou modificar petições e respostas de IA, mover-se lateralmente para a instância de GitLab ou fornecedores de modelos, e até mesmo colocar cargas maliciosas. Em ambientes onde a política do cliente obriga a que os dados de entrada e saída de IA permaneçam dentro do perímetro (self-hosted gateway), a exposição do gateway comprometeria essa garantia e colocaria em risco dados sensíveis. Por se tratar de um componente que costuma ter permissões de rede amplas para se comunicar com GitLab e com APIs externas, a escalada de impacto é plausível.

Recomendações concretas e imediatas (verificáveis e executáveis): 1) Actualizar imediatamente Qualquer AI Gateway self-hosted a uma das versões corrigidas: 19.2.4, 19.3.2 ou 19.4.1 conforme adequado à linha que utilize a sua instalação. Para implantar Docker, parar e remover o contentor actual, fazer docker carregue no novo rótulo e executar o contentor com a mesma configuração; GitLab usa rótulos com nomes como self-hosted-v19.4.1-ee. Para implantação com o Helm, ajuste a imagem no chart (image.tag) e aplique o helm upgrade para colocar a nova etiqueta. 2) Rotar chaves e credenciais sensíveis: se o gateway guarda chaves JWT ou credenciais de fornecedores de modelos, prepare um plano de rotação imediata dessas chaves após a atualização. Embora não haja confirmação de exploração, a rotação atenua o risco de compromisso prévio. 3) Rever e restringir acesso: audite quem tem permissões em Duo Agent Platform e aplique o princípio de menor privilégio; considere desativar a criação de flows por usuários não imprescindíveis até completar a atualização. 4) Monitoramento e busca de indicadores: verifique logs do gateway e do host para detectar execuções anormais, processos desconhecidos, reinícios súbitos ou alterações em configurações de flows; se você tiver snapshots ou cópias de segurança, compárelas para detectar modificações. 5) Ambiente de Teste: primeiro aplique o adesivo em ambientes de staging e valide compatibilidade com a sua versão do GitLab antes de colocar em produção, porque o guia de instalação recomenda usar a imagem de gateway que corresponde à versão menor do GitLab e o aviso não esclarece compatibilidades inversas entre versões.

Ações de mitigação quando não é possível atualizar imediatamente: se por restrições operacionais não puder aplicar o adesivo de imediato, reduza o risco (temporiamente), isolando a rede do gateway para limitar sua capacidade de se comunicar fora do perímetro, aplique controles de firewall para restringir acessos entrantes e salientes, e desative a funcionalidade de flows ou a capacidade de usuários de carregar configurações de flow até que a atualização seja possível. Estas medidas são paliativas e não substituem a atualização do software.

O que comunicar aos equipamentos e próximos passos: informe os equipamentos de segurança e infra-estruturas, documente a versão do gateway e a data/hora da atualização, conserve logs antes de rodar chaves e notificar os departamentos de cumprimento se o gateway gerencia dados regulamentados. GitLab agradeceu ao pesquisador relatante (usuário “invisiblemeerkat” em HackerOne) e já resolveu o problema nos gateways que administra para clientes; no entanto, a responsabilidade de atualização recai nos operadores de gateways self-hosted.

Fontes e leitura adicional: o aviso de segurança do GitLab e a documentação de segurança dos seus serviços estão disponíveis na web do GitLab ( https://about.gitlab.com/security/). A entrada do CVE pode ser consultada no NVD para detalhes estruturados e links associados ( https://nvd.nist.gov/vuln/detail/CVE-2026-90970) e para contexto técnico sobre a classe de fraqueza referida pode ser consultada a definição CWE-1336 no MITRE ( https://cwe.mitre.org/data/definitions/1336.html).

Resumo: Se você hospedar um AI Gateway próprio, atualize já. Se seu GitLab estiver hospedado por GitLab (GitLab.com, GitLab Dedicated ou usa um gateway gerido), GitLab indica que seus gateways já foram adesivos e não é necessária ação por sua parte. Onde não seja possível atualizar imediatamente, isole, restringir acessos e preparar rotações de chaves; documente todas as ações e mantenha uma vigilância reforçada até terminar a contenção e verificação.