GitLab CVE-2026-85706: falha crítica já é explorada

O GitLab corrigiu em 10 de setembro de 2026 uma falha crítica de path traversal (CVE-2026-85706, CVSS 10.0) na API de commits de repositório que permite a um atacante não autenticado ler qualquer arquivo do servidor. Um dia depois, a CISA adicionou a falha ao catálogo Known Exploited Vulnerabilities (KEV) com base em evidência de exploração ativa — e fixou 14 de setembro como prazo de correção para agências federais dos EUA.

Quem é afetado

A falha atinge instalações self-managed do GitLab Community Edition (CE) e Enterprise Edition (EE):

• Versões 18.7 até antes da 19.1.8
• Versões 19.2.x antes da 19.2.6
• Versões 19.3.x antes da 19.3.2

O GitLab.com já roda a versão corrigida e clientes GitLab Dedicated não precisam agir. O risco é exclusivo de quem opera GitLab CE/EE no próprio servidor, seja on-premises ou em VM na nuvem.

O que a falha expõe

Por causa de confinamento de caminho impróprio e falta de checagem de autenticação na API de commits, um atacante remoto sem credenciais consegue enviar uma requisição HTTP manipulada e ler arquivos fora do diretório do repositório — incluindo os que o serviço do GitLab tem permissão de acessar: gitlab.yml, chaves SSH, tokens de acesso, segredos de CI/CD e credenciais de banco de dados. A pesquisadora watchTowr já reproduziu o ataque e registrou sondagens contra sua honeypot logo após a divulgação do patch.

O que fazer agora

1. Atualize toda instância self-managed para 19.1.8, 19.2.6 ou 19.3.2, conforme o branch em uso — confira a versão rodando após o upgrade, não apenas o pacote planejado.
2. Levante o inventário completo de instâncias GitLab, incluindo nós secundários, ambientes de disaster recovery, containers e instâncias atrás de proxy reverso ou load balancer.
3. Se o patch não for imediato, restrinja o acesso ao GitLab a redes de desenvolvimento, administração ou VPN confiáveis enquanto a correção não sai — isso reduz exposição, mas não substitui o upgrade.
4. Audite logs do GitLab, proxy reverso e WAF em busca de requisições POST para /api/v4/projects/{id}/repository/commits/ com parâmetro file.path suspeito, valores de path traversal ou volume incomum de respostas.
5. Se houver indício de exploração, rotacione tokens de CI/CD, chaves de deploy e credenciais de banco que possam ter sido expostas, e revise atividade recente de runners e publicação de pacotes.

Instâncias single-node terão downtime durante a atualização, porque migrações de banco precisam concluir antes do GitLab subir; instalações multi-node podem seguir o procedimento de zero-downtime upgrade da própria documentação.

Perguntas frequentes

O GitLab.com (SaaS) está vulnerável?
Não. A instância gerenciada pelo GitLab já está na versão corrigida desde o dia do patch.

Preciso de credenciais para ser atacado?
Não — a falha não exige autenticação nem interação do usuário, o que a deixa com CVSS 10.0.

Só atualizar resolve, sem checar mais nada?
O patch fecha a falha, mas não desfaz uma leitura de arquivo que já tenha ocorrido. Se a instância ficou exposta antes do upgrade, vale revisar logs e rotacionar segredos.

Conclusão

Com exploração ativa confirmada e prazo federal já vencido em 14 de setembro, toda instância GitLab CE/EE self-managed exposta à internet deveria ter sido atualizada como prioridade máxima. Quem ainda não migrou para 19.1.8, 19.2.6 ou 19.3.2 deve tratar isso como incidente em andamento, não como manutenção de rotina.