O AI Gateway do GitLab deixou uma configuração de fluxo elaborada escapar de seu sandbox de prompt

Em 2 de outubro de 2026, o GitLab publicou uma versão de correção crítica para seu AI Gateway — o middleware que transporta solicitações entre uma instância do GitLab e os modelos de linguagem que os recursos do Duo chamam — atribuindo-lhe a designação CVE-2026-90970 e classificando-a como 9,9 em 10. A falha, nas palavras do próprio GitLab, poderia ter permitido que "um usuário autenticado com acesso ao Duo Agent Platform escapasse da sandbox de templates de prompt por meio de uma configuração de fluxo especialmente elaborada, levando à execução arbitrária de comandos no AI Gateway". Apenas as organizações que executam um AI Gateway auto-hospedado precisavam tomar providências: o GitLab já tinha corrigido os gateways que opera para o GitLab.com, o GitLab Dedicated e clientes auto-geridos que usam um gateway hospedado pelo GitLab, e informou isso no comunicado. O aviso do GitLab não afirma que a falha tenha sido explorada em algum momento, e a avaliação anexada ao registro da CVE pela Agência de Cibersegurança e Segurança de Infraestrutura dos EUA no mesmo dia classifica a exploração como "nenhuma". O crédito pela descoberta foi atribuído ao pesquisador da HackerOne conhecido como invisiblemeerkat. O comunicado do GitLab, o registro do NVD e a cobertura que se seguiu estão de acordo entre si quanto ao que era a falha e quais versões a continham; são igualmente coerentes quanto ao que não se sabe, que é se alguém alguma vez a utilizou. Este registro aparece ao lado das outras vulnerabilidades documentadas de infraestrutura de agentes no arquivo de incidentes de IA, onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e indicador de contestação.

O que o aviso realmente diz, e o que ele deixa de fora

O aviso é curto. Publicado no site de documentação do GitLab com o título "Versão crítica de correção do GitLab AI Gateway: 19.2.4, 19.3.2 e 19.4.1", ele lista uma correção de segurança, intitulada "Problema de neutralização inadequada no modelo de prompt de fluxo personalizado afeta o AI Gateway" e marcada como Crítica. Ele informa o vetor CVSS 3.1 como AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — acessível pela rede, baixa complexidade de ataque, privilégios baixos necessários, nenhuma interação do usuário, escopo alterado e impacto alto na confidencialidade, integridade e disponibilidade. Vale a pena ler esse vetor porque ele é preciso quanto ao atacante: privilégios baixos, mas privilégios ainda assim. O aviso diz "um usuário autenticado com acesso ao Duo Agent Platform" e para por aí. Ele não nomeia a função, a permissão nem as condições a que sua própria expressão "em determinadas condições" se refere.

Não publica uma prova de conceito, não descreve a configuração de fluxo elaborada e não oferece uma solução alternativa para gateways que não podem ser atualizados imediatamente. The Hacker News, em seu relatório de 2 de outubro, observa as mesmas ausências e acrescenta uma que importa operacionalmente: o aviso não fornece nenhuma forma de verificar se um gateway foi atacado antes de ser corrigido. Security Affairs, escrevendo no dia seguinte, registra as mesmas lacunas.

A entrada da enumeração de fraquezas comuns associada ao CVE é CWE-1336, neutralização imprópria de elementos especiais usados em um mecanismo de template. O aviso do GitLab nunca usa a palavra Jinja. A própria documentação do repositório do AI Gateway usa: seu documento de registro de prompts descreve arquivos de configuração de prompts que "oferecem suporte a expressões Jinja para vários papéis, como usuário e sistema", e descreve uma classe Prompt que "usa Jinja para interpolar os modelos de prompt com os argumentos de entrada". A lacuna que o CVE descreve é aquela pela qual esse tipo de mecanismo é famoso — texto fornecido pelo usuário chegando a um template que é avaliado em vez de impresso.

Por que um comando neste host específico vale 9,9

O AI Gateway não é um sidecar. De acordo com a documentação auto-hospedada do GitLab, ele recebe solicitações do GitLab, monta os prompts e se comunica com o backend de modelos — um servidor vLLM, Amazon Bedrock, Azure OpenAI ou um provedor externo — e, em uma implantação totalmente auto-hospedada, é o componente que mantém os prompts e as respostas dentro da rede da própria organização. O guia de instalação do AI Gateway do GitLab também orienta os administradores a gerar um par de chaves de assinatura e passar as duas metades ao serviço como variáveis de ambiente, como AIGW_SELF_SIGNED_JWT__SIGNING_KEY e AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (com equivalentes do Duo Workflow). A Security Affairs deixa a consequência explícita: a execução de comandos no gateway coloca um atacante em um host que guarda material de assinatura JWT e está no caminho entre a instância do GitLab e a infraestrutura de modelos.

Essa é a diferença entre uma fuga de sandbox em um brinquedo e uma em produção. A fuga não precisa chegar a um modelo; precisa chegar ao processo que detém as chaves com as quais as chamadas ao modelo são assinadas.

A documentação do produto do GitLab, separadamente do aviso de segurança, afirma que criar ou editar um fluxo personalizado exige a função de Maintainer ou Owner no projeto de gerenciamento, e que executar um exige Developer ou superior. O aviso de segurança não confirma esse mapeamento, e o The Hacker News observa que nenhuma função é nomeada além de "Duo Agent Platform access". Um leitor que estime sua própria exposição deve tratar a documentação como o modelo de permissões do produto e o silêncio do aviso de segurança como exatamente isso: silêncio, não uma contradição.

Estabelecido, e não estabelecido

Os próprios campos do registro são consistentes com tudo o que foi exposto acima e não acrescentam nada que não esteja no aviso. O que se segue é a divisão que um leitor não consegue obter de um resumo de uma linha.

• Estabelecido: uma falha de severidade crítica no GitLab AI Gateway, divulgada em 2 de outubro de 2026, CVSS 9.9, CWE-1336, alcançável por um usuário autenticado da Duo Agent Platform por meio de uma configuração de fluxo manipulada, resultando em execução de comandos no host do gateway.

• Estabelecido: o intervalo afetado — todas as versões do AI Gateway da 18.1.6 anteriores à 19.2.4, da 19.3 anteriores à 19.3.2 e da 19.4 anteriores à 19.4.1 — e as versões corrigidas, 19.2.4, 19.3.2 e 19.4.1.

• Confirmado:Os gateways hospedados no GitLab foram corrigidos antes da publicação, e seus clientes não precisam tomar nenhuma providência; operadores auto-hospedados foram contatados diretamente antes do post de lançamento, conforme o próprio GitLab declara no aviso.

• Estabelecido: o crédito ao relator, a invisiblemeerkat, e a ausência de qualquer declaração de exploração em ambiente real.

• Não estabelecido: se alguém o explorou. Uma avaliação SSVC da CISA datada de 2 de outubro de 2026 e visível no registro do NVD indica a exploração como "nenhuma", automatizável como "não" e impacto técnico como "total"; o catálogo Known Exploited Vulnerabilities da CISA não listava o CVE-2026-90970 em sua revisão de 20 de outubro de 2026, que verifiquei diretamente. O modelo EPSS da FIRST estimou a probabilidade de exploração nos próximos 30 dias em 0,94 por cento em 21 de outubro de 2026 — baixa, e não zero.

• Não estabelecido: quantos gateways auto-hospedados existem, quantos foram expostos ou se algum foi atacado antes da aplicação da correção. Nenhuma fonte neste registro fornece uma contagem, e o aviso do GitLab não fornece método de detecção.

O intervalo afetado e as versões sem correção listada

A aritmética de versões é menos arrumada do que as três versões corrigidas sugerem. O intervalo afetado começa em 18.1.6, e nenhuma versão corrigida é publicada em qualquer linha abaixo de 19.2.4. Todo gateway da 18.1.6 até a série 19.1, portanto, está dentro do intervalo afetado declarado, sem nenhuma versão corrigida indicada para ele. O The Hacker News destaca a mesma consequência e as perguntas que se seguem: a documentação de instalação do GitLab instrui os administradores a executar a imagem de gateway cuja versão corresponde à sua versão secundária do GitLab, e o aviso não diz se um gateway 19.2.4 funciona com GitLab 19.1 ou anterior, nem se correções para as linhas mais antigas estão planejadas. A política de versões suportadas do GitLab, conforme observa o The Hacker News, atualmente lista 19.4, 19.3 e 19.2 — as mesmas três linhas que receberam correções.

A remediação é uma troca de contêiner, e não um patch: o gateway é distribuído como sua própria imagem Docker ou chart Helm. O guia de instalação do GitLab descreve como parar e remover o contêiner em execução, baixar a nova imagem com a tag self-hosted-vX.Y.Z-ee e iniciá-lo novamente com as variáveis de ambiente intactas; implantações com Helm definem a tag no campo image do chart. Nem o aviso nem o guia de instalação oferecem uma assinatura ou indicador que distinga um gateway atacado de um gateway limpo.

A mesma classe de bug, oito meses antes

Esta não é a primeira vez que o GitLab publica um 9,9 para injeção de template no AI Gateway. Em 6 de fevereiro de 2026, o GitLab lançou as versões 18.6.2, 18.7.1 e 18.8.1 do AI Gateway para CVE-2026-1868, descrito nesse aviso como um "problema de expansão insegura de template", no qual o componente Duo Workflow Service estava "vulnerável à expansão insegura de template de dados fornecidos pelo usuário por meio de definições de Flow do Duo Agent Platform elaboradas", que pode ser usada para negação de serviço ou execução de código no gateway. O vetor CVSS é idêntico ao de outubro, caractere por caractere, e o CWE também. O responsável pelo relato era diferente: aquele foi encontrado internamente, pelo membro da equipe do GitLab Joern Schneeweisz.

O comunicado de outubro não menciona o de fevereiro, e o The Hacker News afirma isso explicitamente. Se os dois compartilham uma causa raiz, uma correção que não se manteve ou meramente uma linguagem e um modelo de ameaça, não é algo que qualquer um dos documentos públicos responda. O que está registrado é que um mecanismo de templates em um componente de middleware de IA já produziu dois comunicados críticos de execução de comandos com a mesma pontuação no mesmo ano, e que o segundo exigiu que um pesquisador externo o encontrasse.

O que mudou, e o que ainda cabe aos operadores decidir

A mudança concreta são três tags de imagem e uma rodada de contato direto. O GitLab diz que contatou clientes do gateway auto-hospedado antes da publicação, e o aviso foi divulgado junto com as imagens corrigidas no mesmo dia. Para todos os outros — GitLab.com, GitLab Dedicated e instâncias autogerenciadas apontadas para um gateway hospedado pelo GitLab — a correção já havia sido aplicada no lado do servidor e, segundo o GitLab, nada era necessário.

Para um operador auto-hospedado, a decisão é mais restrita e menos confortável do que um ciclo normal de correções. Não há solução alternativa para um gateway que não pode ser migrado imediatamente. Não existe um método divulgado para determinar se o host foi comprometido anteriormente, o que significa que a única opção retrospectiva é a habitual: tratar o contêiner como um sistema cuja integridade não está comprovada e procurar sinais de execução fora do seu comportamento normal. E, para gateways nas versões 18.x ou 19.1, o aviso não indica nenhuma versão de destino — uma omissão que o The Hacker News relata e que o comunicado do GitLab não aborda.

A classificação do próprio arquivo é deliberadamente mais restrita que a do fornecedor. Ele registra esta entrada como uma vulnerabilidade, com confiança A, com as fontes em concordância, não contestada, sem danos reais registrados e com um campo de severidade "alta" em contraste com "crítica" do GitLab e do NVD. Essas são respostas para perguntas diferentes: a pontuação descreve o que a falha permitiria, e a avaliação do arquivo descreve o que se sabe ter acontecido. No registro público, nada aconteceu — nenhuma exploração, nenhuma vítima, nenhum relatório de incidente. O valor da entrada é que ela documenta, com um número CVE e uma versão corrigida, exatamente como um template de prompt se tornou uma linha de comando no middleware do qual dependem os recursos de IA corporativa.