Um Único Projeto Público É o Único Requisito
O CVE-2026-85706 quase não exige nada de um atacante para funcionar. A falha reside na API de commits de repositórios do GitLab, onde um confinamento de caminho deficiente e a ausência de uma verificação de autenticação permitem que um utilizador não autenticado envie um pedido com um parâmetro de caminho de ficheiro e receba de volta ficheiros arbitrários do servidor, sem necessidade de sessão iniciada. Jake Knott, da watchTowr, resumiu a barreira de entrada numa única frase: a exploração exige apenas um requisito, ter pelo menos um projeto público. A maioria das instalações GitLab auto-geridas tem pelo menos um, quer o proprietário o veja como voltado para o público ou não.
A falha tem uma pontuação CVSS de 10.0, o máximo permitido pela escala, e afeta o GitLab Community e Enterprise Edition nas versões 18.7 a 19.1.7, 19.2 a 19.2.5 e 19.3 a 19.3.1. Um servidor exposto desta forma não se limita a expor código-fonte. A API de commits está suficientemente próxima dos ficheiros de configuração, das definições de pipelines de CI/CD e dos tokens de deployment para que uma leitura bem sucedida entregue a um atacante as credenciais necessárias para avançar mais fundo em tudo o que essa instalação GitLab constrói e implementa.
Existia Um Patch Antes de Existir o Prazo
| Data | Evento |
|---|---|
| 10 de setembro | O GitLab lança a correção nas versões 19.1.8, 19.2.6 e 19.3.2 |
| 11 de setembro, 06:00 UTC | A rede de honeypots da watchTowr deteta as primeiras tentativas reais |
| 11 de setembro | A CISA acrescenta o CVE-2026-85706 ao seu catálogo de vulnerabilidades exploradas conhecidas |
| 14 de setembro | Prazo para as agências civis federais dos EUA terem aplicado o patch |
Passaram-se menos de 24 horas entre o lançamento da correção e as primeiras tentativas a atingir os honeypots da watchTowr. A entrada no catálogo da própria CISA seguiu-se poucas horas depois. A avaliação da watchTowr é que os atacantes já tinham feito engenharia inversa e reproduzido a vulnerabilidade a partir do próprio patch, o mesmo padrão que transforma uma divulgação numa corrida assim que se torna pública. O prazo da CISA vincula apenas as agências civis federais dos EUA, não uma empresa em Munique ou em Manchester, mas a cronologia de exploração a que está a responder não para nessa fronteira.
A Terceira Que a Servola Acompanha Desde Agosto
Esta não é a primeira falha crítica do GitLab neste verão, é a terceira ativamente explorada em cerca de quatro semanas. A Servola noticiou uma falha do GitLab associada a problemas críticos no Ray e em software da Apple a 18 de agosto, depois uma falha de injeção de código GraphQL no próprio GitLab, o CVE-2026-19478, a 24 de agosto, um erro que a própria cobertura da TheHackerNews sobre esta nova falha liga explicitamente como o caso anterior de exploração pouco depois da divulgação. Três CVEs críticos contra uma única plataforma amplamente auto-alojada num mês não é uma coincidência para desvalorizar como azar. É um sinal de que a superfície de ataque do GitLab, e a velocidade a que investigadores e atacantes fazem hoje engenharia inversa de um patch, ultrapassou a frequência com que a maioria dos proprietários de instalações auto-geridas verifica se existe uma correção.
Nenhuma das três falhas partilha a mesma causa de origem. O que partilham é uma janela temporal comprimida, cada uma foi explorada ou testada dias depois de o patch ser lançado, não semanas. Um proprietário que verificasse as atualizações do GitLab mensalmente teria perdido a janela segura nas três ocasiões.
O Que Muda Para Uma Empresa Que Usa GitLab Auto-Gerido
O passo concreto é pequeno: confirmar que a sua instalação está na versão 19.1.8, 19.2.6 ou 19.3.2 ou posterior, e depois verificar os registos de acesso à procura de pedidos POST contra o endpoint de commits de repositório com um parâmetro de caminho de ficheiro, o indicador que a watchTowr recomenda procurar. O passo maior é o que realmente evita uma repetição. O NIS2 já exige que as organizações da UE demonstrem que conseguem verificar que um patch chegou a cada sistema gerido, e não apenas que o GitLab publicou um. Uma instalação auto-alojada sem ninguém encarregado de vigiar o catálogo KEV da CISA ou os próprios avisos de segurança do GitLab em tempo real vai continuar a descobrir falhas críticas através de uma notícia em vez de um alerta de monitorização, exatamente o tipo de escrutínio que um regulador europeu tenderia a exigir.
Uma empresa que trata cada uma destas falhas como um simulacro de incêndio isolado vai lidar bem com esta e falhar a próxima à mesma velocidade. Uma empresa que atribui a alguém a responsabilidade pelo ritmo de patches do GitLab, da mesma forma que é responsável pelas suas regras de firewall, deixa de estar três em três em deteção tardia.
Leia a seguir: Explorado Semanas Antes de o PaperCut Corrigir | Falha crítica no GitLab atingiu self-hosted, não SaaS
