A GitLab lançou uma atualização de segurança emergencial para corrigir uma vulnerabilidade crítica que pode permitir que invasores não autenticados leiam arquivos arbitrários armazenados em servidores vulneráveis. Identificada como CVE-2026-85706, a falha recebeu a pontuação máxima de 10,0 no CVSS, indicando um nível de risco considerado crítico. Pouco depois da divulgação da correção, pesquisadores observaram tentativas de exploração na internet.
O problema é especialmente preocupante para empresas que mantêm suas próprias instalações do GitLab, conhecidas como ambientes self-managed. Nesses casos, a organização é responsável por instalar as atualizações de segurança e manter a infraestrutura protegida. A versão hospedada diretamente pela GitLab já recebeu as correções necessárias.
Falha permite acessar arquivos sem fazer login
A vulnerabilidade está relacionada a um problema de path traversal, técnica que pode permitir que uma aplicação seja manipulada para acessar arquivos fora do diretório originalmente permitido.
No caso do GitLab, a falha está localizada na API responsável pelo gerenciamento de commits dos repositórios. Segundo as informações divulgadas pela empresa, o problema combina um isolamento inadequado dos caminhos de arquivos com a ausência de mecanismos de autenticação suficientes nesse ponto da aplicação.
Na prática, isso significa que um invasor poderia tentar enviar uma requisição especialmente construída ao servidor e obter acesso a arquivos que deveriam permanecer restritos. O ataque não exige que o criminoso tenha uma conta válida no sistema, o que aumenta consideravelmente a gravidade do problema.
Entre os possíveis alvos estão arquivos de configuração, registros de atividade e outros dados armazenados no servidor. Dependendo do ambiente e das informações presentes nesses arquivos, um invasor poderia encontrar credenciais, tokens, segredos de aplicações ou outras informações utilizadas internamente pela organização.
Esse tipo de acesso é particularmente perigoso porque a leitura de um arquivo aparentemente secundário pode representar apenas a primeira etapa de uma invasão. Caso sejam encontrados dados de autenticação ou chaves utilizadas por outros serviços, o criminoso pode tentar ampliar o acesso para outros sistemas da empresa.
Ataques começaram rapidamente após a divulgação
A velocidade com que a vulnerabilidade passou a ser sondada por invasores chamou a atenção de especialistas.
A empresa de segurança watchTowr identificou tentativas de exploração poucas horas depois da divulgação pública da falha. Segundo os pesquisadores, as primeiras sondagens começaram em 11 de setembro de 2026, um dia depois de o GitLab publicar a atualização de segurança.
O cenário reforça uma preocupação recorrente no setor de segurança: quando uma vulnerabilidade crítica é divulgada e uma correção fica disponível, criminosos podem rapidamente analisar as mudanças feitas no código para descobrir como explorar versões antigas.
Esse intervalo entre a publicação de um patch e a instalação da atualização pelos administradores pode ser suficiente para colocar milhares de servidores em risco.
A situação ficou ainda mais séria quando a Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA) incluiu a CVE-2026-85706 em seu catálogo de vulnerabilidades exploradas ativamente, conhecido como KEV. A inclusão significa que a falha deixou de ser apenas uma possibilidade teórica e passou a ser tratada como uma ameaça utilizada em ataques reais.
Quais versões do GitLab estão vulneráveis?
A falha afeta diferentes versões do GitLab Community Edition (CE) e Enterprise Edition (EE).
De acordo com o alerta de segurança, estão vulneráveis:
- versões 18.7 até antes da 19.1.8;
- versões 19.2 anteriores à 19.2.6;
- versões 19.3 anteriores à 19.3.2.
Para corrigir o problema, os administradores devem atualizar as instalações para 19.1.8, 19.2.6 ou 19.3.2, conforme a linha utilizada.
A recomendação é especialmente importante para organizações que utilizam o GitLab em servidores próprios e disponibilizam pelo menos um projeto público. Pesquisadores apontaram que a existência de um projeto público pode ser uma das condições necessárias para explorar a vulnerabilidade.
Outra vulnerabilidade também foi corrigida
A mesma atualização de segurança resolveu ainda outro problema importante no GitLab Enterprise Edition.
Trata-se da CVE-2026-87719, uma falha de desserialização insegura classificada com pontuação 9,9 no CVSS. Nesse caso, o ataque exige autenticação e acesso ao recurso Duo Chat, mas pode permitir que um usuário obtenha configurações da infraestrutura de Advanced Search e credenciais sensíveis por meio de argumentos especialmente manipulados.
A existência de duas vulnerabilidades graves na mesma atualização aumenta a importância de realizar a atualização completa, em vez de tentar corrigir apenas o problema considerado mais urgente.
Por que a falha representa um risco para empresas?
O GitLab é utilizado por equipes de desenvolvimento para armazenar código-fonte, controlar alterações, administrar projetos e automatizar processos de desenvolvimento e entrega de software.
Isso faz com que uma instalação comprometida possa representar um risco muito maior do que a simples exposição de um servidor. Repositórios podem conter códigos proprietários, arquivos de configuração, chaves de API, tokens de acesso e informações relacionadas à infraestrutura de uma organização.
Além disso, o GitLab frequentemente está integrado a ferramentas de integração contínua e entrega contínua, os chamados CI/CD. Essas integrações podem possuir permissões para executar tarefas automaticamente em servidores, nuvens e outros sistemas corporativos.
Por isso, uma invasão bem-sucedida pode criar oportunidades para ataques posteriores. Um criminoso que consiga descobrir uma credencial armazenada em um arquivo de configuração, por exemplo, pode tentar utilizá-la para acessar outro serviço.
É importante destacar que a existência da vulnerabilidade não significa que todos os servidores afetados tenham sido invadidos. No entanto, diante da confirmação de exploração ativa, organizações que ainda não instalaram as correções devem considerar seus ambientes potencialmente expostos e investigar sinais de atividade suspeita.
O que administradores devem fazer?
A principal recomendação é atualizar imediatamente as instalações self-managed do GitLab para uma versão corrigida. A própria documentação da empresa reforça a necessidade de aplicar as versões de segurança disponibilizadas para cada ramo do produto.
Além da atualização, empresas devem verificar os registros de acesso e procurar requisições incomuns direcionadas à API de commits. Também é recomendável investigar se arquivos potencialmente sensíveis foram acessados durante o período em que o servidor estava vulnerável.
Outro cuidado importante é a rotação de credenciais. Caso exista qualquer possibilidade de que tokens, senhas, chaves ou segredos tenham sido expostos por meio da vulnerabilidade, eles devem ser substituídos. A simples instalação do patch não necessariamente elimina o risco de uma credencial que já tenha sido copiada por um invasor.
A situação do GitLab serve como mais um exemplo de como vulnerabilidades críticas podem passar rapidamente da divulgação para a exploração. Quando uma falha recebe nota máxima de gravidade e ataques começam a ser registrados pouco depois da publicação da correção, o tempo de resposta passa a ser um dos principais fatores para evitar um incidente.
