O GitLab publicou em 10 de setembro de 2026 uma correção de emergência para uma falha de gravidade máxima. Menos de 24 horas depois do anúncio, atacantes já sondavam instalações vulneráveis. Registrada como CVE-2026-85706, a vulnerabilidade recebeu nota 10.0 no CVSS, a pontuação mais alta possível, e permite que uma pessoa sem autenticação leia arquivos armazenados no servidor. As versões corrigidas são 19.3.2, 19.2.6 e 19.1.8.
O alerta se aplica a instalações autogerenciadas das edições Community (CE) e Enterprise (EE). O GitLab.com já usa a versão corrigida, enquanto clientes do GitLab Dedicated não precisam fazer nada. Estão vulneráveis as versões a partir da 18.7 até a 19.1.7, além das versões 19.2.0 a 19.2.5 e 19.3.0 a 19.3.1.
Uma requisição anônima basta
A vulnerabilidade está na API de commits do repositório. De acordo com o GitLab, o problema resulta da combinação de um confinamento de caminho inadequado, conhecido como path traversal, com a falta de autenticação obrigatória no endpoint. Na prática, uma requisição HTTP pode deixar a pasta prevista e tentar ler arquivos em qualquer ponto do servidor. A exploração exige que a instância tenha pelo menos um projeto público.
O acesso pode alcançar chaves SSH, tokens de implantação, variáveis de CI/CD, credenciais de banco de dados e arquivos de configuração do próprio GitLab. Esses dados podem abrir caminho para o código-fonte e para os pipelines de build, segundo a empresa de segurança watchTowr. Por isso, o problema não se limita à leitura de um arquivo isolado. Uma credencial exposta pode dar ao invasor condições de avançar dentro do ambiente.
A mesma atualização corrige outras duas falhas de segurança, ambas na edição Enterprise. A CVE-2026-87719, com CVSS 9.9, permite que um usuário autenticado com acesso ao Duo Chat obtenha configurações e credenciais do Advanced Search. O ataque usa um argumento manipulado em uma subscription GraphQL, contorna a serialização e provoca a busca de objetos no servidor.
A CVE-2026-88765, com CVSS 8.5, permite execução remota de código. Para isso, o invasor importa um export de projeto manipulado que estoura o buffer de conversão Unicode usado na indexação do Advanced Search. A tabela oficial do pacote lista 18 correções de segurança no total.
Ataques começaram em menos de 24 horas
A watchTowr registrou sondagens em massa contra o endpoint a partir das 06:00 UTC de 11 de setembro, 3h no horário de Brasília. A atividade começou poucas horas depois da publicação da correção. “Permite que atacantes leiam arquivos arbitrários em uma única requisição HTTP”, afirmou a empresa. Jake Knott, chefe de inteligência de ameaças da watchTowr, disse que o interesse dos criminosos está no acesso que uma instância comprometida pode oferecer: código-fonte, segredos de CI/CD, credenciais e a chance de injetar código nos pipelines de build.
No mesmo dia 11, a CISA incluiu a CVE-2026-85706 no catálogo de vulnerabilidades já exploradas e deu até 14 de setembro para que agências federais dos Estados Unidos aplicassem a correção. A agência também determinou triagem forense, já que algumas instâncias podem ter sido acessadas antes da existência do patch. Qualquer instalação autogerenciada exposta na internet antes de 10 de setembro deve ser tratada como potencialmente comprometida até que uma investigação descarte essa possibilidade.
Este é o segundo caso neste ano de uma falha crítica no GitLab explorada poucos dias após a divulgação. Em agosto, a CVE-2026-19478, uma falha de injeção de código na API GraphQL com CVSS 9.4, foi reproduzida por pesquisadores da watchTowr em minutos e explorada em cerca de 48 horas. Em julho, um episódio parecido atingiu o WordPress: a falha wp2shell passou a ser usada em massa no fim de semana seguinte à correção.
Um levantamento citado pelo CySecurity News, com dados do Shodan e do Censys, identificou mais de 20 mil instâncias autogerenciadas de GitLab acessíveis pelas portas web padrão. O número não indica quantas estão vulneráveis, mas mostra o tamanho da superfície exposta na internet.
O que fazer agora
O GitLab recomenda atualizar para 19.1.8, 19.2.6 ou 19.3.2. Em instalações de nó único, o serviço fica indisponível durante a janela de atualização, pois as migrações de banco precisam terminar antes da retomada. Ambientes multinó que usam um procedimento de zero downtime conseguem aplicar a correção sem interromper o serviço. A versão 19.3.2 também traz migrações pós-deploy, executadas depois da atualização.
Se a atualização imediata não for possível, a watchTowr recomenda examinar os logs em busca de requisições POST para /api/v4/projects/{id}/repository/commits/ com o parâmetro file.path. Uma chamada legítima desse endpoint não usa esse parâmetro. Por isso, cada registro desse tipo deve ser investigado como uma possível tentativa de exploração. Depois da correção, é necessário rotacionar as credenciais que possam ter aparecido nos arquivos acessíveis, incluindo tokens, chaves SSH e variáveis de CI/CD.
O GitLab mantém fechado por 90 dias o detalhamento técnico de cada falha e só publica os relatórios depois desse prazo. A CVE-2026-85706 foi reportada pelo pesquisador conhecido como s3ntago por meio do programa de recompensas por bugs da empresa, hospedado na HackerOne.
Fontes: GitLab, BleepingComputer, SecurityWeek, CySecurity News
