Fuga de sandbox no GitLab AI Gateway: o que o pentest pega

O GitLab corrigiu em 2 de outubro uma falha no seu AI Gateway que permitia a um usuário autenticado, com acesso à plataforma de agentes, escapar do sandbox de prompt template e executar comandos arbitrários no servidor. CVSS 9.9, criticidade máxima. O que me interessa não é o número. É que a falha não foi um modelo disobediente, nem um prompt malicioso, nem alguém sem credencial. Foi alguém com a credencial certa fazendo uma coisa que não devia, atravessando uma fronteira que ninguém tinha testado. Esse é o trabalho de pentest, e é o que quase ninguém está contratando para fazer.

O que você leva deste texto: por que “sandbox de prompt” não é um controle de segurança, e o que colocar no escopo de teste de qualquer aplicação com IA antes que o pentest saia de moda.

O que o GitLab contou

Segundo o advisory oficial do GitLab, a falha é o CVE-2026-90970, classificada como “Improper Neutralization issue in custom flow prompt template impacts AI Gateway”, com severidade crítica e CVSS 9.9.

O texto do aviso é preciso, e vale ler com calma, porque ele descreve exatamente o tipo de coisa que a maior parte do mercado ainda chama de “vulnerabilidade de IA”: “under certain conditions, could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway”.

Traduzindo: um usuário autenticado, com acesso legítimo à plataforma, fornecia uma configuração de fluxo construída para o efeito. O sandbox que deveria segurar o prompt template não segurou. O que estava do outro lado não era uma resposta indevida de modelo, era execução de comando no host.

O crédito do reporte responsável vai para o invisiblemeerkat, pelo HackerOne. O GitLab afirma ter feito contato direto com os clientes que rodam a própria instância antes de publicar o aviso.

As versões corrigidas são 19.2.4, 19.3.2 e 19.4.1. São afetadas todas as versões a partir da 18.1.6 até antes dessas três. Quem usa o AI Gateway hospedado pelo GitLab, em GitLab.com, Dedicated ou Self-Managed, já está protegido e não precisa fazer nada. Quem mantém a instância self-hosted, essa é sua.

Uma coisa precisa ficar clara, porque a notícia vai circular mal: o advisory não diz que essa falha foi explorada. Não há exploração ativa declarada. O que existe é uma vulnerabilidade crítica num componente que milhões de empresas usam em produção.

O ponto que ninguém vai escrever: prompt não é fronteira

Existe uma crença conveniente no mercado de que uma aplicação com IA fica segura porque o modelo não obedece a instruções maliciosas. A crença é intuitiva e está errada no ponto exato que importa.

Modelo não é controle de acesso. Modelo é um componente que produz texto. O que impede um usuário de fazer algo indevido é autorização, validação de entrada e uma fronteira de processo, testadas com credencial válida.

O CVE-2026-90970 é a prova em formato de advisory: o vetor é uma configuração de fluxo malformada, o atacante é um usuário autenticado com acesso à plataforma, e o resultado é escape de sandbox para execução de comando. Nada disso exige que o modelo seja manipulado. O modelo só estava ali, fazendo o trabalho dele, dentro de uma estrutura que se supunha segura.

Quem tem IA em produção costuma ter duas coisas: o time de app testou a API com entrada malformada e o time de segurança testou a infraestrutura. O meio-termo, a camada que decide o que um usuário autenticado pode fazer dentro do fluxo de IA, quase ninguém olha. É exatamente ali que o GitLab estava exposto.

O lugar comum do GitLab

Não é acaso a empresa ter dois casos graves em um mês. Em setembro, o GitLab corrigiu o CVE-2026-85706, um path traversal de severidade máxima que permitia a atacantes não autenticados ler credenciais e outros segredos de servidores vulneráveis. O CISA acrescentou a falha ao catálogo de vulnerabilidades exploradas e deu três dias para as agências federais corrigirem, sob a diretriz BOD 26-04.

Desde novembro de 2021, o CISA marcou cinco vulnerabilidades do GitLab como exploradas, segundo a BleepingComputer, uma delas por grupos de ransomware.

Duas falhas graves no mesmo produto, em menos de um mês, uma delas já na mão de atacantes. Isso não é estatística de mercado. É evidência de que a superfície de uma plataforma que cresceu rápido está crescendo mais rápido do que o teste que acompanha.

E continua existindo um motivo para o patch não bastar: mesmo com a versão corrigida aplicada, você ainda precisa saber se a sua instância está exposta por outra via e se alguém mais tem acesso a ela. Versão atualizada é o começo da conversa, não o fim.

O que eu colocaria no escopo de qualquer aplicação com IA

Não é checklist da OWASP. É o que eu pediria para testar, e a ordem importa.

Primeiro, autorização por passo, não por sessão. Um usuário autenticado deveria conseguir fazer exatamente o que a sua função permite. Na prática, o modelo continua sendo “tem acesso, logo pode”. Teste cada transição de estado do fluxo com uma credencial de privilégio menor e veja se ela passa.

Segundo, fronteira de processo com saída. Se o seu backend tem uma camada de IA que processa template, dado do usuário e chamada de ferramenta, essa fronteira precisa existir fora do prompt. Prompt que tenta não permitir é prompt que pode ser permitido.

Terceiro, configuração como superfície de ataque. No caso do GitLab, o vetor foi a configuração, não a requisição. Fluxo customizado, agente, definição de ferramenta, template, variável de ambiente: cada uma dessas coisas é entrada controlada por alguém e merece o mesmo tratamento que parâmetro de API. A maioria dos times trata configuração como decisão de engenharia interna. Ela é decisão de usuário.

Quarto, relatório que separa o que foi testado do que não foi. Aqui é onde a IA complica tudo, porque gera superfície nova rápido demais. Um relatório honesto que lista o que não foi coberto vale mais que um relatório bonito que esconde o buraco.

O que fazer agora

• Coloque no escopo do próximo teste a camada de autorização do fluxo de IA, não só a API e a infraestrutura.
• Trate configuração de agente, template e definição de ferramenta como entrada não confiável, e teste com usuário de baixo privilégio.
• Verifique se existe fronteira de processo entre a camada de IA e o que ela pode alcançar. Se a resposta é “o prompt diz para não fazer”, você não tem controle, tem sugestão.
• Peça relatório com o que não foi testado, e retest depois da correção, como sempre.
• Se você opera o AI Gateway self-hosted do GitLab, atualize para 19.2.4, 19.3.2 ou 19.4.1. Se usa o hospedado, não precisa fazer nada.

Vale dizer o que o PentestBR não faz: não testamos o modelo, não fazemos red team de prompt e não prometemos saber o que a IA “pensa”. Testamos a aplicação. A fronteira entre o que o usuário pode fazer e o que ele não pode é propriedade da aplicação, e foi exatamente isso que quebrou no caso do GitLab.

Prompt injection é o assunto que todo mundo quer discutir. Fuga de sandbox por usuário autenticado é o que realmente tira serviço do ar. O primeiro já tem nome próprio. O segundo é CVE com data de publicação.