GitLab corrige CVE-2026-85706, falha CVSS 10 explorada para roubar arquivos sem autenticação

A CVE-2026-85706 recebeu CVSS 10.0 e já está sendo explorada contra instalações self-managed do GitLab CE e EE. A falha permite que um atacante remoto, sem autenticação, leia arquivos arbitrários do servidor quando a instância possui ao menos um projeto público.

O problema afeta versões do GitLab CE/EE entre 18.7 e 19.1.7, entre 19.2 e 19.2.5 e entre 19.3 e 19.3.1. Segundo a cobertura da InfoQ, a correção exige atualizar para 19.1.8, 19.2.6 ou 19.3.2, conforme a linha utilizada.

Como a leitura de arquivos acontece

A vulnerabilidade combina confinamento inadequado de caminhos com ausência de aplicação de autenticação na API de commits de repositório. Em determinadas condições, isso abre espaço para path traversal: o caminho recebido pela API pode escapar do local que deveria limitar o acesso e alcançar outros arquivos no servidor.

O vetor está associado a requisições HTTP POST direcionadas a URIs no formato:

POST /api/v4/projects/{id}/repository/commits/

A exploração envolve parâmetros file.path. Como não há uma etapa de autenticação no cenário vulnerável, basta existir um projeto público para atender à condição mínima descrita no material apurado.

Isso transforma uma falha de leitura em um risco maior para a infraestrutura. Arquivos do servidor podem conter variáveis de CI/CD, tokens de runners, chaves SSH, tokens de deploy, configurações e dados registrados em logs. Se essas credenciais derem acesso a outros recursos, o invasor pode avançar para pipelines, pacotes, imagens e sistemas conectados ao GitLab.

Exploração começou após a divulgação

A vulnerabilidade foi reportada por Mohamed Abdelaiz, conhecido como S3ntago, e corrigida pelo GitLab em 11 de setembro. Horas depois da divulgação, a empresa de segurança watchTowr identificou sondagens em ambiente real. Posteriormente, a CISA incluiu a falha em seu catálogo Known Exploited Vulnerabilities.

A sequência reduz a margem para tratar a atualização como manutenção programada. Instâncias públicas e vulneráveis devem ser consideradas expostas a tentativas de exploração, mesmo quando não existe evidência imediata de comprometimento.

Além das versões principais corrigidas, o GitLab publicou, duas semanas depois, backports para as versões 19.0.9 e 18.11.12 das edições Community e Enterprise. Essas duas linhas já estavam em fim de vida, segundo a apuração publicada pela InfoQ.

Atualizar não encerra a resposta

A atualização impede novas leituras pela vulnerabilidade, mas não invalida segredos que possam ter sido copiados antes da correção. Por isso, a resposta precisa combinar patch, investigação e rotação de credenciais.

A recomendação da watchTowr é procurar nos logs requisições POST para o endpoint de commits contendo parâmetros file.path. Essa busca pode indicar tentativas de exploração, embora a ausência de registros encontrados não seja, por si só, prova de que nenhum arquivo foi acessado.

Também é necessário rotacionar tokens de deploy, variáveis de CI/CD, tokens de runners e chaves SSH potencialmente expostos. A análise deve alcançar os recursos consumidos pelos pipelines enquanto as credenciais antigas ainda eram válidas, incluindo pacotes e imagens obtidos pelos builds.

Reduzir a exposição da instância à internet complementa essas medidas. Essa restrição não substitui a atualização, mas diminui a superfície disponível para novas tentativas.

Ressalvas e prioridade prática

O cenário descrito é específico para instalações self-managed do GitLab CE e EE nas faixas afetadas. A condição conhecida exige pelo menos um projeto público, mas isso não deve ser interpretado como garantia de segurança permanente para ambientes que hoje não atendem ao requisito: configurações e visibilidade de projetos podem mudar.

A análise dos logs também depende da retenção e da integridade dos registros disponíveis. Se o período relevante não estiver armazenado, a investigação terá alcance limitado e a rotação preventiva de segredos ganha mais importância.

A resposta imediata faz sentido para qualquer instância self-managed exposta publicamente e dentro das versões vulneráveis: atualizar, procurar indicadores e substituir credenciais. O que não faz sentido é encerrar o incidente após instalar o patch. Como a falha permite exfiltração sem login, a correção do software resolve o vetor, mas não desfaz um possível vazamento anterior.