CVE-2026-85706: falha CVSS 10 no GitLab já é explorada e exige atualização imediata

A CVE-2026-85706 é uma vulnerabilidade de travessia de diretórios (path traversal) de gravidade máxima em instalações autogerenciadas do GitLab Community Edition (CE) e Enterprise Edition (EE). Com nota 10,0 no CVSS 3.1, ela pode permitir que uma pessoa sem autenticação, sob determinadas condições, leia arquivos arbitrários no servidor GitLab. Não é apenas um risco teórico: a CISA, agência de cibersegurança dos Estados Unidos, já a incluiu entre as vulnerabilidades conhecidas por estarem sendo exploradas, enquanto pesquisadores relataram sondagens contra instâncias expostas na internet logo após a disponibilização das correções. 32122

Prioridade imediata: atualizar

Se uma instância autogerenciada do GitLab estiver em uma versão vulnerável, a recomendação é atualizar o mais rápido possível para uma versão corrigida:

• 19.1.8 ou posterior;
• 19.2.6 ou posterior;
• 19.3.2 ou posterior.

As faixas afetadas são GitLab CE/EE 18.7 até antes da 19.1.8, 19.2 até antes da 19.2.6 e 19.3 até antes da 19.3.2. As correções foram lançadas em 10 de setembro de 2026. 37

A CISA adicionou a CVE-2026-85706 ao catálogo Known Exploited Vulnerabilities (KEV) em 11 de setembro, estabelecendo 14 de setembro como prazo de ação para agências civis federais dos EUA cobertas pela determinação. Esse prazo não se aplica automaticamente a empresas privadas, mas sinaliza a urgência para qualquer instalação autogerenciada acessível pela internet. 3

O que a vulnerabilidade permite fazer

A falha está na API Repository Commits do GitLab. A causa documentada combina confinamento inadequado de caminhos controlados pelo usuário com ausência de aplicação de autenticação. Nessas condições, uma requisição sem autenticação pode ser usada para ler arquivos arbitrários que estejam acessíveis ao serviço GitLab. 3

Trata-se, principalmente, de uma vulnerabilidade de exposição de arquivos. As informações disponíveis não comprovam que a CVE-2026-85706, isoladamente, permita execução remota de código. Ainda assim, a leitura arbitrária de arquivos pode revelar material útil para um comprometimento posterior, conforme a configuração do servidor — como configurações da aplicação, tokens, chaves SSH, credenciais de banco de dados e outros segredos que o processo do GitLab consiga ler. 925

Por que a exploração ativa muda a resposta

A watchTowr informou ter observado sondagens reais para a vulnerabilidade, inclusive em sua rede de honeypots em 11 de setembro. A entrada da CISA no KEV também é um alerta importante: o catálogo existe para apontar vulnerabilidades com evidências de exploração fora de ambientes de teste. 222

Os relatos públicos confirmam sondagens e atividade de exploração, mas não identificam um único responsável, não trazem uma contagem confiável de vítimas nem comprovam uma cadeia de comprometimento posterior aplicável a todos os casos. A falta de um incidente conhecido, portanto, não deve ser tratada como prova de que um servidor exposto não foi acessado.

Considere instâncias expostas como possível caso de vazamento de segredos

Aplicar o patch interrompe o comportamento vulnerável, mas não desfaz dados que possam já ter sido lidos. Em servidores afetados e acessíveis pela internet, preserve evidências e avalie o que a conta de serviço do GitLab conseguia acessar antes de iniciar uma limpeza ampla.

A revisão e a rotação devem priorizar, entre outros itens:

• segredos de aplicação e de configuração do GitLab;
• credenciais de banco de dados, Redis, armazenamento de objetos, registro de contêineres, SMTP, serviços de diretório e provedores de identidade armazenadas na configuração;
• variáveis de CI/CD, deploy tokens, access tokens, tokens de runners, chaves de implantação e credenciais montadas para jobs ou integrações;
• chaves de nuvem, credenciais de registros de pacotes, chaves de assinatura e chaves privadas SSH ou TLS acessíveis pelo host ou pelo processo GitLab.

A rotação precisa ser planejada. Alterar segredos da aplicação ou configurações associadas à criptografia pode invalidar sessões e interromper configurações criptografadas ou integrações. Primeiro, retenha os logs e as evidências de configuração relevantes, defina procedimentos de recuperação e então faça a rotação dos segredos mais críticos em uma sequência controlada.

Detecção: por onde começar a procurar

Um indicador inicial útil é uma requisição HTTP POST para o caminho da API Repository Commits:

/api/v4/projects/<id>/repository/commits/

Os relatos recomendam, especificamente, buscar requisições com o parâmetro file.path. Analise logs de proxy reverso, balanceadores de carga, WAF e acesso do GitLab Rails em busca de requisições incomuns sem autenticação, entradas codificadas com aparência de travessia de diretórios, IDs de projeto inesperados, falhas repetidas, padrões de enumeração ou respostas com tamanho anormal. 212426

Também vale investigar atividades possivelmente relacionadas após a janela de exposição suspeita, como criação ou uso de novos tokens, registro de runners, alterações em variáveis de CI/CD ou definições de pipelines, importações incomuns, atividade em GraphQL e conexões de saída inesperadas. As orientações divulgadas após o lançamento também pedem revisão de commits, assinaturas GraphQL, importações de projetos e pipelines de CI/CD. 23

Uma busca sem resultados nos logs não é conclusiva. A retenção pode ser limitada, o registro da aplicação pode não conter os detalhes relevantes e os registros de proxy ou WAF podem ser a única evidência disponível.

Controles temporários se a atualização atrasar

A atualização é a correção necessária. Se não for possível fazer uma atualização emergencial de imediato, reduza a exposição restringindo o acesso ao serviço web e à API do GitLab a uma VPN ou a redes autorizadas. Uma regra de proxy reverso ou WAF que limite estritamente a rota afetada da API Repository Commits pode reduzir o risco no curto prazo, mas pode quebrar automações legítimas e não substitui o patch.

Para cada servidor afetado, a sequência prática de resposta é:

1. Identificar e priorizar instâncias autogerenciadas alcançáveis externamente.
2. Atualizar para 19.1.8, 19.2.6, 19.3.2 ou versão mais recente.
3. Confirmar a versão em execução após a mudança.
4. Preservar e revisar os logs em busca de indicadores de exploração.
5. Rotacionar segredos potencialmente expostos de acordo com o acesso do servidor e o impacto para o negócio.

Outras vulnerabilidades corrigidas no lançamento

A mesma cobertura de segurança também descreveu duas falhas do Enterprise Edition corrigidas no lançamento:

• A CVE-2026-87719 é relatada como uma falha autenticada de desserialização insegura, com CVSS 9,9, associada em alguns relatos à exposição de configurações e credenciais do Advanced Search. 6
• A CVE-2026-88765 é relatada como um risco de execução remota de código autenticada por meio da importação de uma exportação maliciosa de projeto Git, com CVSS 8,5. 625

Essas falhas têm pré-requisitos e efeitos diferentes da CVE-2026-85706. Para instalações GitLab autogerenciadas expostas à internet, a vulnerabilidade sem autenticação e sob exploração ativa deve continuar sendo a primeira prioridade de contenção e resposta a incidentes.