Falha no GitLab permite ler arquivos sem login e entra no KEV da CISA

CVSS 10 e prazo de três dias para corrigir

A CISA incluiu a CVE-2026-85706 no catálogo KEV, reservado a falhas comprovadamente exploradas. A vulnerabilidade atinge o GitLab CE/EE em versões self-managed específicas e recebeu CVSS 10, o teto da escala de gravidade.

Sondagens em ambiente real foram detectadas por volta das 06:00 UTC de 11/09. A CISA adicionou a falha ao KEV no mesmo dia, definiu prazo de remediação em 14/09 e exigiu triagem forense conforme a BOD 26-04. O intervalo entre a primeira varredura e o prazo oficial deixou pouquíssimo espaço para planejamento.

A API de commits entrega arquivos que deveria proteger

O defeito está na API de commits de repositório do GitLab. Sem qualquer login, um atacante consegue manipular caminhos de arquivo e fazer o servidor devolver conteúdos que deveriam permanecer fechados. É o clássico problema de confinamento de caminho: a aplicação não delimita até onde uma requisição pode navegar no sistema de arquivos.

O agravante é a combinação de leitura arbitrária de arquivos sem autenticação. Não há necessidade de conta, senha ou acesso prévio ao GitLab, o que elimina praticamente toda a barreira de entrada para quem encontra uma instância exposta.

Como medir sua exposição em minutos

O primeiro passo é mapear se existe GitLab self-managed acessível pela internet no seu ambiente. O GitLab.com já consta como protegido, mas instâncias próprias dependem inteiramente da ação do time interno.

• Versões afetadas citadas: 18.7 até 19.1.7, 19.2 até 19.2.5 e 19.3 até 19.3.1.
• Versões corrigidas citadas: 19.1.8, 19.2.6 e 19.3.2.
• Sinal de alerta: tentativas incomuns contra endpoints da API de commits de repositório.
• Prioridade alta: ambientes expostos, com código-fonte, tokens de CI/CD ou segredos armazenados.

Patch primeiro, investigação logo em seguida

A prioridade absoluta é atualizar o GitLab para uma das versões corrigidas. Só que o patch resolve o futuro, não o passado: como há exploração ativa confirmada e exigência de triagem forense, a correção precisa vir acompanhada de investigação sobre o que já pode ter sido lido.

• Atualize para 19.1.8, 19.2.6 ou 19.3.2, conforme sua trilha de versão.
• Revise logs de acesso relacionados à API de commits e a leituras de arquivos incomuns.
• Troque tokens de CI/CD e segredos que possam ter ficado acessíveis no servidor.
• Reduza exposição pública se a instância não precisar estar aberta à internet.
• Registre evidências antes de apagar logs, para apoiar análise e resposta a incidente.

Checklist pratico

1. Confirme se sua instância GitLab CE/EE está nas faixas afetadas informadas.
2. Aplique a atualização corrigida correspondente e valide se o serviço voltou corretamente.
3. Faça triagem forense: logs, acessos suspeitos, arquivos sensíveis, tokens e segredos.

Perguntas frequentes

Quem usa GitLab.com precisa corrigir algo?

O GitLab.com já consta como protegido. A urgência recai sobre instâncias self-managed que rodam as versões afetadas.

Por que essa falha é tão grave?

Porque dispensa autenticação e atinge ativos de altíssimo valor: código-fonte proprietário, tokens de CI/CD e segredos de pipeline.

Atualizar é suficiente?

Atualizar é obrigatório, mas não encerra o caso. Com exploração ativa registrada, também é preciso investigar sinais de acesso indevido anteriores ao patch.

Conheca: Pentest, Threat Intelligence com IA, Conscientizacao de Seguranca, SGSI, Plano Diretor de Seguranca, Auditoria Interna, Governanca de MFA e Cofre TOTP, ISO 42001 - IA, Diagnostico Gratuito de Seguranca. lcsec.io

Fontes: