Vulnerabilidade no GitLab AI Gateway Rompe o Sandbox e Permite Execução de Comandos

O GitLab corrigiu uma vulnerabilidade no GitLab AI Gateway classificada em 9,9 de 10, após pesquisadores encontrarem um caminho para execução arbitrária de comandos. A falha afeta gateways auto-hospedados e exige um usuário autenticado com acesso à GitLab Duo Agent Platform. Um fluxo personalizado especialmente elaborado pode escapar do sandbox de modelos de prompt e executar comandos com os privilégios do processo do gateway.

O incidente tem alcance mais limitado do que uma falha explorável remotamente que afetasse todas as implantações do GitLab. Os gateways hospedados pelo GitLab foram corrigidos pela empresa, e clientes que usam esses serviços não precisam atualizar o gateway por conta própria. Organizações que operam um AI Gateway auto-hospedado têm a responsabilidade imediata.

Essa distinção cria a tensão central. A auto-hospedagem dá a uma organização maior controle sobre o processamento de IA, a infraestrutura e os caminhos de dados. Também transfere ao cliente as responsabilidades de aplicação de patches, monitoramento e contenção. Neste caso, o componente colocado dentro do ambiente confiável tornou-se um alvo de execução de comandos.

A vulnerabilidade é rastreada como CVE-2026-90970. O GitLab lançou as versões 19.2.4, 19.3.2 e 19.4.1 do AI Gateway em 2 de outubro de 2026. A empresa pediu aos operadores afetados que atualizassem imediatamente, mas seu aviso público não identificou uma solução alternativa nem forneceu orientações detalhadas para detecção de comprometimento.

A Vulnerabilidade no GitLab AI Gateway Exige Atualização Imediata

O fato urgente é simples: gateways auto-hospedados afetados precisam de uma versão corrigida do AI Gateway, e não apenas de uma aplicação GitLab atualizada.

O aviso de patch crítico do GitLab identifica três versões corrigidas: 19.2.4, 19.3.2 e 19.4.1. O número de versão relevante pertence ao componente AI Gateway. Ele não deve ser confundido com a versão de uma instância GitLab conectada.

O intervalo afetado começa com o AI Gateway 18.1.6. Ele inclui versões anteriores à 19.2.4, a versão 19.3 anterior à 19.3.2 e a versão 19.4 anterior à 19.4.1. Organizações que executam uma ramificação mais antiga ainda suportada devem selecionar a versão corrigida apropriada.

A redação também importa para instalações nas linhas 18.x e 19.1. O GitLab não listou uma versão corrigida do gateway abaixo da 19.2.4 no aviso de outubro. Operadores nessas linhas não devem presumir que permanecer em uma ramificação mais antiga oferece proteção.

Um AI Gateway auto-hospedado é executado como um serviço separado, normalmente por meio de uma implantação em container ou Helm. Atualizar a aplicação principal do GitLab não prova automaticamente que a imagem do gateway foi substituída. Administradores devem inspecionar a própria implantação do gateway e confirmar sua tag de imagem em execução.

O GitLab afirmou ter contatado clientes de gateways auto-hospedados antes de publicar o aviso. Também disse que uma correção já havia chegado aos gateways hospedados pelo GitLab. Isso protege GitLab.com, GitLab Dedicated e instâncias autogerenciadas conectadas a um gateway hospedado pelo GitLab.

Esse escopo torna a identificação de ativos o primeiro desafio operacional. Uma equipe de segurança pode saber que sua organização usa GitLab Duo sem saber qual modelo de gateway o suporta. O serviço pode ser operado pelo GitLab ou implantado dentro do ambiente do cliente.

As equipes devem verificar essa distinção por meio de registros de implantação, inventários de containers, releases Helm e configuração do GitLab Duo. Devem evitar inferir a propriedade do gateway apenas pelo nome do produto GitLab. Uma instância GitLab autogerenciada ainda pode usar um gateway hospedado pelo GitLab.

O registro CVE atribui à vulnerabilidade os impactos máximos em confidencialidade, integridade e disponibilidade dentro de seu vetor CVSS 3.1. A pontuação é 9,9 em vez de 10 porque a exploração exige baixos privilégios. Ela não requer interação do usuário, e o serviço vulnerável pode ser alcançado pela rede.

Baixo privilégio não significa acesso anônimo. O GitLab afirma que um invasor precisa estar autenticado e ter acesso à Duo Agent Platform. Esse requisito reduz a população inicial de invasores, mas inclui contas comprometidas e possíveis agentes internos mal-intencionados.

A falha atravessa uma fronteira de segurança após esse acesso inicial. Um usuário autorizado a trabalhar com fluxos de IA não deveria herdar permissão para executar comandos do sistema operacional no gateway. A vulnerabilidade transforma acesso em nível de aplicação em controle sobre um ambiente de execução mais sensível.

Os operadores devem tratar a atualização como uma alteração independente, com evidências independentes. Um ticket de mudança concluído para o GitLab não estabelece que o AI Gateway está seguro. A evidência correta é a versão do gateway em execução e uma implantação verificada em todas as réplicas.

Essa verificação deve incluir ambientes de desenvolvimento, staging, recuperação de desastres e ambientes temporariamente reduzidos. Instâncias de gateway esquecidas ainda importam se mantiverem conectividade de rede ou credenciais. Uma interface inativa não garante um serviço inacessível.

Um Fluxo Personalizado Transformou Dados de Modelo em Comportamento Executável

A falha central não foi um modelo de IA escrever um comando perigoso. Foi uma fronteira de modelo permitir que dados elaborados alcançassem um comportamento executável da aplicação.

O GitLab descreve o problema como neutralização inadequada em um modelo de prompt de fluxo personalizado. Um fluxo personalizado é um fluxo de trabalho de IA configurável e com várias etapas dentro da Duo Agent Platform. Ele pode combinar prompts, componentes, decisões de roteamento e ferramentas em uma definição YAML.

A documentação de fluxos personalizados da empresa mostra por que essas definições são mais do que texto de prompt comum. Os fluxos podem ser criados, testados, publicados, habilitados para projetos e acionados por atividades do GitLab. Eles funcionam como configuração de aplicação em torno de um agente.

O caminho vulnerável envolvia um sandbox de modelo de prompt. Um sandbox é um ambiente de execução restrito, destinado a impedir que um modelo alcance atributos ou funções inseguras. O CVE-2026-90970 permitia que uma configuração de fluxo elaborada escapasse dessas restrições.

Um ticket de divulgação público do GitLab atribui o problema ao acesso inseguro a métodos durante a renderização de modelos Jinja2. Jinja2 é um mecanismo de modelos Python que combina texto com variáveis e expressões.

Segundo o ticket, o histórico de conversas continha um objeto HumanMessage do LangChain. O modelo podia chamar um método público de desserialização nesse objeto. Uma carga serializada insegura então fazia o Python executar comandos do sistema operacional durante a desserialização.

A desserialização converte dados armazenados ou transmitidos de volta em um objeto de programa. Ela se torna perigosa quando o formato selecionado pode invocar código ao reconstruir esse objeto. Dados Python pickle são um exemplo conhecido, pois carregar conteúdo pickle não confiável é inseguro.

A prova de conceito relatada usou um fluxo de duas etapas. A primeira interação com o modelo preenchia o histórico da conversa. Uma avaliação posterior do modelo acessava esse objeto do histórico e acionava o caminho perigoso de desserialização.

Essa sequência torna o problema diferente de um bug básico de injeção de shell. O valor malicioso não precisava aparecer como um parâmetro de comando direto passado a um shell. Em vez disso, vários recursos individualmente significativos formaram a cadeia de execução.

O fluxo aceitava conteúdo de prompt configurável. O mecanismo de modelos recebia objetos da aplicação. Um objeto expunha um método de desserialização. O formato de serialização aceito podia invocar código. Juntas, essas condições derrotaram o sandbox pretendido.

O próprio modelo não era a fronteira de segurança confiável. Ele ajudava a avançar o fluxo entre estados, mas o comando era executado por meio de comportamento determinístico da aplicação. Filtrar apenas a saída do modelo não resolveria a relação vulnerável entre objeto e modelo.

Essa distinção importa quando organizações classificam falhas de segurança em IA. Injeção de prompt descreve tentativas de manipular um modelo por meio de instruções. O CVE-2026-90970 é uma vulnerabilidade de software no sistema que envolve o modelo, embora um modelo de prompt forneça o ponto de entrada.

Portanto, práticas tradicionais de segurança de aplicações continuam essenciais. Entradas de modelos precisam de validação rigorosa, objetos expostos precisam de interfaces mínimas e formatos perigosos de desserialização não devem processar dados controlados por invasores. Sandboxes também precisam ser testados contra os objetos exatos disponibilizados dentro deles.

Os comandos relatados foram executados com os privilégios do processo Duo Workflow Service. Isso limita a autoridade imediata no sistema operacional às permissões da conta de serviço. Ainda assim, a execução no nível do serviço é séria porque o gateway lida com conexões sensíveis e está dentro de uma infraestrutura confiável.

O impacto prático depende da arquitetura de implantação. Um container com privilégios mínimos e rede restrita apresenta menos caminhos subsequentes do que um serviço com ampla conectividade. Nenhuma das configurações elimina a necessidade de aplicar o patch, porque um invasor ainda obteria execução de código não intencional.

Esse mecanismo explica a severidade próxima do máximo. O invasor começa com uma identidade autenticada capaz de usar o Duo, mas a execução resultante atravessa para o contexto de segurança do gateway. Essa mudança de escopo é central para a classificação 9,9.

A Auto-Hospedagem Transfere Controle e Responsabilidade de Segurança em Conjunto

O incidente expõe o trade-off por trás da infraestrutura de IA auto-hospedada: manter o processamento próximo também coloca o gateway dentro da fronteira de confiança operacional do cliente.

O GitLab descreve o AI Gateway como um serviço independente que conecta recursos do GitLab Duo a modelos de IA. Clientes podem usar o gateway gerenciado do GitLab ou operar seu próprio gateway com GitLab Duo Self-Hosted.

Organizações frequentemente escolhem a auto-hospedagem para controlar a movimentação de dados, o acesso a modelos, as rotas de rede e a política de infraestrutura. Esses benefícios podem ser importantes em ambientes regulamentados ou em implantações com controles internos rígidos. Eles também criam outro serviço de produção que os clientes devem inventariar e manter.

A vulnerabilidade no GitLab AI Gateway transforma esse detalhe operacional na principal questão de segurança. O GitLab pôde implantar uma correção diretamente nos gateways que gerencia. Clientes auto-hospedados devem programar, executar e verificar suas próprias atualizações.

Esse padrão é familiar em bancos de dados, serviços de identidade e runners de CI. A diferença é que gateways de IA unem sistemas que antes eram separados de forma mais clara. Eles ficam entre usuários, repositórios de código-fonte, fluxos de trabalho de agentes, provedores de modelos e, às vezes, ferramentas de execução.

Um gateway comprometido, portanto, merece mais atenção do que uma interface isolada de chatbot. Dependendo da configuração, ele pode encontrar conteúdo de prompts, estado de fluxos de trabalho, credenciais de serviço, conexões de provedores ou metadados sobre atividade interna de desenvolvimento.

Isso não estabelece que o CVE-2026-90970 expôs todos os segredos conectados. O aviso do GitLab não relata roubo de dados confirmado nem um caminho completo de pós-exploração. A conclusão correta é que a execução arbitrária de comandos cria uma rota plausível para acesso adicional.

As equipes devem avaliar o gateway como um serviço de integração privilegiado. Sua identidade de processo, arquivos montados, variáveis de ambiente, rotas de rede e contas de serviço associadas determinam o raio de impacto. Esses controles se tornam importantes ao reconstruir a exposição antes da aplicação do patch.

A conteinerização ajuda apenas quando seus limites são configurados deliberadamente. Um contêiner ainda pode alcançar serviços de rede, ler segredos montados ou enviar dados para fora. Sua segurança efetiva depende das permissões de execução e das políticas ao redor.

O guia de instalação do GitLab recomenda restringir o acesso de rede de saída para o contêiner do AI Gateway. O controle de egress limita quais destinos um processo comprometido pode contatar. Ele pode reduzir a utilidade da execução de comandos, embora não elimine o impacto local.

A segmentação de rede fornece outra camada de contenção. Um gateway precisa acessar endpoints definidos do GitLab e de modelos, mas raramente precisa de alcance irrestrito por uma rede interna. Listas de permissões restritas tornam movimentos laterais inesperados mais difíceis.

O desenho das credenciais importa igualmente. Segredos de longa duração armazenados diretamente no ambiente criam alvos atraentes após uma exploração. Credenciais de curta duração, contas de serviço isoladas e permissões estritamente delimitadas podem reduzir os danos após o comprometimento de um serviço.

As equipes de segurança também devem examinar quem pode criar ou modificar fluxos personalizados. A documentação do GitLab atribui ações de gerenciamento de fluxos a funções como Maintainer ou Owner em diversos fluxos de trabalho. A exposição exata ainda depende da configuração do produto e da implementação afetada.

O aviso usa a expressão mais ampla “Duo Agent Platform access” em vez de nomear uma única função de projeto exigida universalmente. Administradores não devem transformar exemplos da documentação em um pré-requisito definitivo para a exploração. Eles devem revisar as permissões reais e as alterações históricas nos fluxos.

A hospedagem própria continua sendo uma escolha arquitetural válida. A lição não é que um serviço gerenciado seja sempre mais seguro. A lição é que o controle dos dados, o controle do software e a responsabilidade por incidentes vêm juntos.

Um gateway gerenciado concentra a confiança nas operações do fornecedor. Um gateway auto-hospedado concentra a confiança na aplicação de patches, no isolamento e no monitoramento do cliente. O CVE-2026-90970 torna essa troca visível porque o limite de correção acompanha exatamente o limite de hospedagem.

Para compradores corporativos, a revisão de segurança deve abranger tanto os recursos do produto quanto a responsabilidade pela implantação. Perguntas sobre por onde os dados trafegam devem ser acompanhadas de perguntas sobre quem aplica patches em cada componente. Um diagrama de arquitetura sem responsabilidade operacional permanece incompleto.

Um Patch Corrige a Falha, Mas Deixa Questões de Detecção

A atualização interrompe o caminho vulnerável conhecido, mas o aviso público não informa aos operadores como provar que uma exploração anterior jamais ocorreu.

Até 4 de outubro, o GitLab não havia declarado publicamente que o CVE-2026-90970 estava sendo explorado em ataques reais. Essa ausência é tranquilizadora, mas não comprova que todas as implantações afetadas permaneceram intactas.

Os detalhes técnicos públicos aumentam a importância da aplicação rápida de patches. O ticket de divulgação descreve a relação entre os objetos vulneráveis e relata execução bem-sucedida de comandos em um ambiente de staging. Defensores e atacantes podem estudar esse material.

O GitLab creditou o pesquisador do HackerOne conhecido como invisiblemeerkat pela divulgação responsável. O relato responsável deu ao GitLab tempo para preparar correções e contatar clientes afetados. Isso não eliminou a janela de exposição para implantações que permanecem sem patch após a publicação.

O requisito de autenticação deve orientar a busca por ameaças. As equipes de segurança devem começar pelas identidades do Duo Agent Platform, pelos eventos de gerenciamento de fluxos e pelas alterações nas definições de fluxos personalizados. Elas devem correlacionar esses registros com a atividade do gateway durante o período vulnerável.

Configurações incomuns de fluxo merecem revisão, especialmente modelos que acessam objetos de histórico de conversas ou invocam métodos. Criação, edição, publicação ou execução inesperada de fluxos pode fornecer contexto adicional. Nomes de fluxo aparentemente normais não devem se sobrepor a comportamentos suspeitos de modelos.

A atividade do processo do gateway também importa. Processos filhos, invocação de shell, binários inesperados, acesso incomum a arquivos e conexões de saída podem indicar execução de comandos. Os dados úteis dependem da telemetria de contêiner, host e nuvem já habilitada.

Reinicializações de contêineres podem apagar evidências locais. Portanto, logs centralizados e telemetria de segurança de runtime são mais úteis do que inspecionar apenas um contêiner em execução no momento. As equipes devem preservar os logs disponíveis antes de substituir a infraestrutura se suspeitarem de comprometimento.

Os operadores devem revisar os segredos acessíveis ao processo do gateway. As decisões de rotação devem seguir as evidências e a exposição, não o pânico. Se os logs indicarem execução de comandos, presuma que credenciais legíveis podem ter sido acessadas.

As conexões do gateway com o GitLab e os provedores de modelos merecem atenção separada. Um invasor que obteve execução de comandos pode tentar reutilizar tokens, inspecionar a configuração ou alcançar serviços conectados. O registro público não confirma que tal atividade tenha ocorrido.

O patch não deve encerrar a investigação quando houver evidências suspeitas. A atualização remove o caminho de código conhecido, mas não revoga credenciais roubadas nem desfaz alterações feitas em outros locais. Os procedimentos de resposta a incidentes continuam necessários.

Há também uma razão histórica para cautela. Relatos de segurança identificaram uma questão anterior do AI Gateway em 2026, o CVE-2026-1868, com a mesma classificação 9.9 e a mesma categoria de fraqueza CWE-1336. Essa falha também envolvia conteúdo de fluxo manipulado e possível execução de código.

Dois problemas de alta gravidade em mecanismos de template não provam que todo fluxo personalizado seja inseguro. Eles justificam uma revisão mais rigorosa de como templates, objetos de aplicação e serialização se encontram dentro de sistemas de agentes.

A recorrência sugere que os testes de segurança precisam abranger composições, não apenas componentes isolados. Um sandbox pode se comportar corretamente diante de strings, mas falhar quando objetos ricos de framework entram em seu contexto. Um método seguro em uma camada pode se tornar perigoso quando templates conseguem invocá-lo.

As plataformas de agentes intensificam esse problema porque unem muitos mecanismos flexíveis. Prompts, ferramentas, históricos, lógica de roteamento, respostas de modelos e APIs de aplicações interagem em etapas repetidas. Um estado introduzido em uma etapa pode se tornar uma entrada executável posteriormente.

As organizações devem adicionar fluxos personalizados adversariais aos testes de pré-implantação. Os testes devem incluir acesso a métodos, travessia de objetos, limites de serialização e alterações de estado em múltiplas etapas. Uma varredura de prompt em uma única passagem não representaria a cadeia de exploração relatada.

Elas também devem tratar templates como artefatos próximos ao código. Revisão, propriedade, histórico de alterações e controles de implantação devem corresponder ao seu impacto potencial. Chamar um arquivo de “configuração” não reduz sua capacidade de alterar o comportamento em runtime.

O GitLab não detalhou publicamente todas as condições exigidas para a exploração. Isso limita uma avaliação confiante da exposição. As equipes devem usar os pré-requisitos divulgados como condições mínimas, sem presumir que condições não especificadas garantam segurança.

Três Sinais Mostrarão se a Resposta Está Funcionando

A próxima fase depende da adoção de patches, de evidências de exploração no mundo real e do tratamento mais profundo do GitLab para o isolamento de fluxos personalizados.

O primeiro sinal é a porcentagem de gateways auto-hospedados executando 19.2.4, 19.3.2, 19.4.1 ou uma versão corrigida posterior. Cada organização deve medir isso em todos os ambientes e réplicas. Números de toda a indústria podem permanecer indisponíveis porque essas implantações ficam dentro das redes dos clientes.

A adoção rápida reduziria a superfície de ataque alcançável após a divulgação pública. A adoção lenta estenderia o risco, especialmente onde os serviços de IA ficam fora dos inventários estabelecidos de gerenciamento de vulnerabilidades. A responsabilidade pelos gateways deve se tornar visível nos painéis de patches.

O segundo sinal é qualquer mudança no status de exploração. GitLab, CISA, empresas de resposta a incidentes e clientes afetados podem publicar indicadores ou casos confirmados. Um relato de exploração ativa mudaria a prioridade da aplicação preventiva de patches para uma resposta a incidentes mais ampla.

Os defensores devem distinguir uma prova de conceito pública de ataques observados. A reprodução técnica prova que a falha funciona nas condições documentadas. Ela não estabelece que invasores comprometeram clientes em produção.

O terceiro sinal é uma mudança estrutural de segurança no AI Gateway. Um patch restrito pode bloquear a chamada de método divulgada. Uma resposta mais ampla pode reduzir quais objetos chegam aos templates, proibir serialização perigosa ou fortalecer o isolamento em torno dos fluxos personalizados.

Essa resposta de design importa porque a cadeia relatada surgiu da composição de recursos. Impedir uma carga útil é útil, mas eliminar o limite inseguro de capacidade oferece proteção mais forte contra variantes.

As futuras notas de lançamento e alterações de código do GitLab devem esclarecer qual camada recebeu a correção. Administradores devem acompanhar novas orientações sobre validação de fluxos, eventos de auditoria, consultas de detecção e caminhos de atualização compatíveis para ramificações mais antigas do gateway.

Clientes corporativos podem usar o incidente para testar agora seu próprio modelo operacional. A questão importante não é simplesmente se o GitLab aparece no inventário de software. É se o AI Gateway existe como um serviço com propriedade separada, atualizado, registrado em logs e isolado.

Desenvolvedores que criam fluxos também devem reconsiderar a confiança atribuída à configuração. Um fluxo personalizado pode coordenar ferramentas e dados de aplicações em múltiplas etapas. Ele deve receber o mesmo ceticismo aplicado a scripts de automação e definições de CI.

Revisores de segurança devem mapear quatro limites: quem pode criar fluxos, quais objetos os templates podem acessar, quais ferramentas os fluxos podem invocar e quais privilégios o processo do gateway possui. A fragilidade em vários limites pode transformar acesso limitado em controle da infraestrutura.

Profissionais do conhecimento que usam o GitLab Duo não precisam abandonar o trabalho comum por causa deste aviso. A maioria não consegue determinar por conta própria quem é responsável pelo gateway. Eles devem seguir as orientações da organização e relatar comportamentos inesperados dos fluxos, em vez de tentar testes independentes.

Administradores têm uma ação mais clara. Identifiquem o modelo de hospedagem, confirmem a versão do gateway em execução, implantem o patch correto e preservem evidências onde houver atividade suspeita. Revisem as alterações de fluxo e a telemetria do gateway durante o período vulnerável.

Após aplicar o patch, documentem o resultado em um registro operacional durável. Registrem a versão anterior, o horário de implantação, os ambientes afetados, o método de verificação e quaisquer conclusões da busca por ameaças. Essa evidência dá suporte a futuras auditorias e à reconstrução de incidentes.

A vulnerabilidade do GitLab AI Gateway é, em última análise, um alerta sobre onde a lógica de aplicações de IA se torna software executável convencional. A falha começou em um template de prompt, atravessou um objeto de framework e terminou com comandos do sistema operacional.

Esse caminho merece mais atenção do que apenas o rótulo “IA”. Os modelos podem influenciar fluxos de trabalho, mas os limites convencionais de software ainda determinam se uma entrada não confiável se torna código. As organizações precisam de controles em torno das duas camadas.

Se sua organização opera o GitLab Duo, faça hoje uma pergunta concreta: quem é responsável pelo gateway que processa essas solicitações? Se a resposta for sua equipe, verifique a versão em relação às versões corrigidas do GitLab. Em seguida, teste se seu monitoramento revelaria comandos inesperados, fluxos alterados ou conexões de saída. O patch corrige a vulnerabilidade divulgada do GitLab AI Gateway, mas a segurança duradoura depende de inventário, isolamento e evidências que sobrevivam ao próximo aviso.