Vulnerabilidade crítica no GitLab permite exfiltração de dados sem autenticação e já está sob ataque

Uma vulnerabilidade de path traversal no GitLab saiu da categoria de risco teórico para exploração confirmada em campo. A CVE-2026-85706 afeta instâncias self-managed do GitLab Community Edition (CE) e Enterprise Edition (EE) e permite que um atacante remoto, sem nenhuma autenticação, leia arquivos arbitrários do servidor. A falha recebeu a nota máxima da escala CVSS, 10.0, e já foi adicionada ao catálogo de vulnerabilidades conhecidas exploradas (KEV) da CISA, segundo reportagem da InfoQ.

Para quem mantém GitLab em produção no Brasil, isso não é um alerta genérico de patch pendente: é uma falha que já está sendo testada por atacantes em instâncias reais, com um pré-requisito tão baixo que boa parte dos ambientes corporativos se qualifica sem perceber.

O que a CVE-2026-85706 expõe

A causa raiz, segundo a descrição técnica citada pela InfoQ, é confinamento impróprio de caminho (path confinement) combinado com ausência de verificação de autenticação na API de commits de repositório. Na prática, isso significa que a rota que deveria servir arquivos de um commit específico pode ser manipulada para ler qualquer arquivo acessível ao processo do GitLab.

O alvo mais valioso não é código-fonte: é configuração. Segundo o executivo de segurança Parker Brisette, os arquivos expostos por esse tipo de falha costumam ser exatamente o que um invasor precisa para escalar o ataque.

Em um servidor GitLab, os arquivos arbitrários são variáveis de CI/CD, tokens de runner e o que mais os logs capturaram. Jake Knott, da watchTowr, resumiu bem a pré-condição: basta existir um projeto público. Depois disso, não há etapa de autenticação.

On a GitLab server the arbitrary files are CI/CD variables, runner tokens, and whatever the logs picked up. watchTowr's Jake Knott put the precondition plainly. One public project has to exist. After that there is no authentication step.Parker Brisette, Chief Information Security Officer

Ou seja: variáveis de CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps →, tokens de runner e segredos de configuração são o tipo de dado que vaza por esse caminho, e não exige credencial nenhuma para ser lido.

O único pré-requisito é ter um projeto público

Diferente de falhas que dependem de configurações exóticas, a exploração desta aqui tem um gatilho simples: basta que a instância GitLab tenha pelo menos um projeto público. Isso cobre instâncias usadas para open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → interno, portais de documentação pública, ou qualquer servidor self-managed que tenha, propositalmente ou por descuido, um repositório sem restrição de acesso.

As versões afetadas cobrem uma faixa ampla do GitLab CE/EE:

• 18.7 até 19.1.7
• 19.2 até 19.2.5
• 19.3 até 19.3.1

A falha foi reportada por Mohamed Abdelaiz (identificado como S3ntago) e corrigida pelo GitLab em 11 de setembro de 2026. A firma de segurança watchTowr registrou sondagens de exploração em ambiente real poucas horas depois da divulgação pública, segundo a InfoQ.

Patch corta leitura nova, mas não apaga o que já vazou

O ponto mais relevante para quem administra uma instância GitLab não é só atualizar: é entender que o patch resolve o vetor de ataque, mas não desfaz o estrago de quem já foi explorado antes da correção. É o alerta feito pelo executivo de cibersegurança Christopher Houser.

Aplicar o patch impede novas leituras. Ele não revoga os tokens de deploy, as variáveis de CI e as chaves SSH que um invasor já copiou. Rotacione essas credenciais e depois verifique quais pacotes e imagens seus builds baixaram enquanto as credenciais antigas ainda eram válidas.

Patching stops new reads. It doesn't revoke the deploy tokens, CI variables, and SSH keys an attacker already copied. Rotate those, then check which packages and images your builds pulled while the old credentials were still valid.Christopher Houser, executivo de cibersegurança

Na prática, para um time que mantém GitLab self-managed, a resposta correta a esse tipo de CVE tem três camadas, não uma:

1. Atualizar a versão (fecha a porta de entrada)
2. Rotacionar tokens de deploy, variáveis de CI/CD e chaves SSH (invalida o que já pode ter vazado)
3. Auditar builds e imagens que rodaram enquanto as credenciais antigas ainda eram válidas (verifica se algo malicioso entrou na cadeia de supply chain)

Essa terceira camada é a que mais costuma ser ignorada, e é justamente onde mora o risco de comprometimento de pipeline de CI/CD e de acesso lateral a outros sistemas que o GitLab tem permissão de tocar.

Como caçar sinais de exploração nos logs

A watchTowr recomenda que times de segurança vasculhem logs HTTP em busca de requisições POST para rotas no padrão /api/v4/projects/{id}/repository/commits/ que contenham o parâmetro file.path. Esse é o rastro deixado por tentativas de explorar a falha, mesmo quando o ataque não teve sucesso.

Um usuário identificado como GuffariBranderr8, em discussão no Reddit sobre o caso, reforçou que a resposta ao incidente precisa ir além de aplicar o patch:

Se configurações sensíveis ou credenciais de CI/CD forem expostas, um invasor pode potencialmente usá-las para alcançar outros sistemas; por isso, restringir a exposição à internet e rotacionar os segredos afetados devem fazer parte da resposta, junto com o patch.

If sensitive configuration or CI/CD credentials are exposed, an attacker could potentially pivot into other systems, so restricting internet exposure and rotating affected secrets solo be part of the response alongside patching.GuffariBranderr8, usuário no Reddit

Quais versões aplicar e o detalhe do backport para versões EOL

Para instâncias self-managed, as versões corrigidas são:

Duas semanas depois do patch inicial, o GitLab fez algo que chama atenção: fez backport da correção também para as versões 19.0.9 e 18.11.12 do CE e EE, mesmo essas duas linhas já estando em fim de vida (end-of-life). É um sinal de quão grave a equipe de segurança do GitLab considerou o CVSS 10.0, justificando suporte extra a versões que, em tese, não receberiam mais patch algum.

Para quem ainda roda uma dessas versões EOL por falta de janela de upgrade, o backport compra tempo, mas não troca a urgência de planejar a migração para uma linha ativamente suportada: o próximo CVE crítico pode não ganhar o mesmo tratamento.

O que ainda fica em aberto

A InfoQ não traz números públicos de quantas instâncias foram efetivamente comprometidas antes da correção, nem detalha se o GitLab.com (SaaS) foi afetado da mesma forma ou se o problema é restrito a self-managed, como indicado pela reportagem. Times que usam o GitLab hospedado por conta própria, especialmente com projetos públicos ativos entre 18.7 e 19.3.1, são quem precisa agir primeiro: checar logs, atualizar e rotacionar segredos, nessa ordem.

Fonte: InfoQ