Falha máxima no GitLab permite ler arquivos secretos sem senha — e já está sendo explorada em massa

Introdução

A agência de cibersegurança dos EUA alertou que hackers já estão explorando ativamente uma falha de severidade máxima no GitLab (plataforma DevSecOps usada para versionar código-fonte, automatizar pipelines de CI/CD e armazenar segredos de aplicações). Rastreada como CVE-2026-85706, a vulnerabilidade tem nota CVSS 10.0 — o máximo da escala — e permite que um atacante não autenticado leia credenciais, tokens e outros arquivos arbitrários diretamente do servidor com uma única requisição HTTP.

O GitLab corrigiu o problema em 10 de setembro nas versões 19.3.2, 19.2.6 e 19.1.8 do Community Edition (CE) e Enterprise Edition (EE). Menos de 24 horas depois, a empresa de pesquisa watchTowr (especializada em segurança ofensiva, exposição de superfícies de ataque e simulação de invasões) já observava varreduras em massa na internet contra instâncias não corrigidas. No dia seguinte, a CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA — o link aponta para o catálogo de falhas com exploração ativa confirmada) incluiu o CVE no catálogo KEV, com prazo de três dias para agências federais mitigarem o risco.

Por que o GitLab é um alvo de elite para atacantes

Um servidor de código-fonte concentra, em um único lugar, o que um invasor mais quer: código proprietário, chaves de API, tokens de deploy, senhas de banco, certificados e variáveis secretas de CI/CD usadas para publicar aplicações. Diferente de um website comum, onde uma leitura de arquivos costuma expor só configuração, aqui o roubo de um único arquivo de segredos pode dar ao atacante as credenciais da infraestrutura inteira da empresa.

A escala do GitLab amplifica o problema: a plataforma é usada por mais de 50% das empresas da Fortune 100 e soma mais de 30 milhões de usuários registrados no mundo. No Brasil, é comum encontrar instâncias self-managed — instaladas nos próprios servidores da empresa — em fintechs, provedores de infraestrutura e times de desenvolvimento de médio e grande porte. Essas instâncias, muitas vezes expostas na internet para acesso remoto de equipes, são exatamente o alvo das varreduras automáticas que começaram menos de um dia após o patch.

O tema de proteger esse tipo de infraestrutura vai além desta falha pontual — e por isso vamos aprofundá-lo no sub-artigo Segurança de GitLab/CI-CD, que detalha boas práticas de endurecimento para servidores de código. Esta matéria, porém, foca no que precisa ser feito agora: a vulnerabilidade tem exploração ativa confirmada e o prazo de mitigação para agências federais expira em 14 de setembro.

A falha: path traversal sem autenticação na API de commits

O CVE-2026-85706 combina dois defeitos na API de commits de repositórios do GitLab (repository commits API — o endpoint usado para listar e inspecionar commits de um projeto): ausência de enforcement de autenticação e confinamento impróprio de caminho. Juntos, eles permitem que qualquer pessoa na internet — sem login, sem token, sem nenhuma credencial — leia arquivos arbitrários do sistema operacional que hospeda o GitLab.

O primeiro defeito é uma falha de path traversal (CWE-35), classe de vulnerabilidade em que o atacante manipula o parâmetro de caminho de um arquivo com sequências de navegação (como ../) para escapar do diretório permitido e alcançar arquivos fora do repositório. O segundo é a falta de verificação de autenticação no fluxo atingido: a rota processa a requisição sem exigir que o chamador esteja identificado.

O fluxo de exploração, conforme descrito pelo pesquisador s3ntago no programa de bug bounty da GitLab (HackerOne) e confirmado pelo advisory oficial, ocorre em etapas:

A requisição. Tudo começa com um POST direcionado ao endpoint de commits de um projeto público ou adivinhável, sem enviar qualquer token de autenticação.

O caminho manipulado. O atacante insere sequências de path traversal no parâmetro que indica o caminho do arquivo, tentando navegar para fora do diretório do repositório — na direção de arquivos como o de configuração de segredos do GitLab, chaves privadas ou variáveis de ambiente do servidor.

O confinamento que não confina. Por causa do defeito na validação, o servidor resolve o caminho sem impedir a saída do diretório permitido e devolve o conteúdo do arquivo na resposta — tudo em uma única troca de pacotes, sem brute force, sem etapas intermediárias.

O vetor CVSS (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N) resume o tamanho do estrago: explorável remotamente pela rede, baixa complexidade, sem privilégios, sem interação do usuário e com impacto alto de confidencialidade — exatamente a leitura arbitrária de arquivos — além de impacto alto de integridade, já que os segredos lidos podem permitir manipular pipelines, commits e deploys.

As versões afetadas e corrigidas, segundo o advisory oficial da GitLab:

O ciclo disclosure, probe e exploração em menos de 24 horas

O caso do CVE-2026-85706 é um retrato quase perfeito do ritmo atual da exploração de vulnerabilidades: entre o patch e as varreduras em massa, passaram-se horas, não semanas.

O aviso da watchTowr foi direto sobre o que vem depois das varreduras:

Com base em vulnerabilidades recentes do GitLab, sabemos que o tempo até a exploração indiscriminada provavelmente não está longe. Defensores também devem caçar nos arquivos de log requisições HTTP POST para URIs /api/v4/projects//repository/commits/ contendo parâmetros file.path, para identificar possíveis tentativas de exploração.

Nota de transparência: a exploração ativa foi confirmada pela CISA ao incluir o CVE no KEV, e a watchTowr observou probes em massa na internet. Até o fechamento desta matéria, nenhum ator específico foi nomeado publicamente e não há vítimas brasileiras confirmadas — o que não reduz a urgência: a janela entre o patch e a exploração indiscriminada, como o próprio caso demonstra, costuma ser de dias.

O que significa estar no KEV da CISA (e o prazo do BOD 26-04)

Entrar no catálogo KEV da CISA (Known Exploited Vulnerabilities — a lista oficial de falhas com exploração ativa confirmada, mantida pela agência dos EUA) não é um selo de "risco teórico": é a confirmação de que atores maliciosos estão usando a falha em ataques reais. Para quem administra uma instância GitLab self-managed, a consequência prática é direta — se o servidor estava exposto na internet entre 10 e 14 de setembro, ele pode muito bem ter sido varrido, e qualquer arquivo sensível pode ter sido lido.

A entrada no KEV acionou o BOD 26-04 (Binding Operational Directive — diretiva vinculante da CISA que obriga agências do governo federal dos EUA a corrigirem vulnerabilidades do catálogo em prazos rígidos), com três dias para mitigação: adicionada em 11/09, vencimento em 14/09. O registro ainda marca a necessidade de forensic triage — ou seja, a agência deve tratar qualquer instância potencialmente afetada como possivelmente comprometida e auditar evidências, não apenas aplicar o patch.

Embora a diretiva seja obrigatória apenas para agências federais (FCEB), a CISA foi explícita ao encorajar todo o setor privado a adotar a mesma priorização: falhas do KEV são vetores frequentes de ataque e representam risco significativo para qualquer organização.

O padrão é conhecido. Em janeiro deste ano, o GitLab já havia corrigido um bypass de autenticação de dois fatores (2FA) de alta severidade. Desde novembro de 2021, a CISA marcou quatro vulnerabilidades do GitLab como exploradas ativamente — incluindo CVE-2021-22175 e CVE-2021-39935, ambas adicionadas em fevereiro de 2026. É o mesmo enredo de outras inclusões recentes no KEV que cobrimos aqui: o RCE no RouterOS da MikroTik explorado para instalar shell sem senha e o bypass de autenticação no Cisco FMC explorado por três gangues — appliances e servidores que, uma vez acessíveis na internet, viram alvo de exploração em massa em questão de dias.

Detecção: a regra de logs da watchTowr

Para quem não sabe se foi alvo, a watchTowr publicou uma regra de detecção simples e direta: procurar nos logs de acesso requisições HTTP POST para o endpoint de commits da API — /api/v4/projects//repository/commits/ — que contenham o parâmetro file.path. É a assinatura da tentativa de exploração: o parâmetro legítimo da API de commits não é usado dessa forma em tráfego normal.

Uma linha suspeita nos logs do proxy ou do nginx do GitLab teria esta forma:

POST /api/v4/projects/123/repository/commits/?file.path=../../../etc/gitlab/gitlab-secrets.json HTTP/1.1

Em um servidor Linux, a busca pode começar com um comando simples nos logs de acesso do nginx ou do balanceador que fica à frente da instância:

grep -E "repository/commits" /var/log/nginx/access.log | grep "file.path"

Em ambientes maiores, a caça deve ser automatizada. O primeiro passo é centralizar os logs de acesso do GitLab (nginx, proxy reverso e logs de aplicação) em um Wazuh (SIEM open source que centraliza a coleta de logs e permite correlacionar eventos de segurança em tempo real), que já é usado no site como ferramenta de referência para hunting em logs. Em seguida, cria-se uma regra de correlação que dispare quando um evento HTTP registre método POST, URI contendo repository/commits e presença de file.path — o mesmo padrão da regra da watchTowr, expresso em termos de campos do agente. Por fim, com a regra ativa, qualquer tentativa de exploração contra o endpoint passa a gerar alerta com o IP de origem, horário e parâmetros usados, permitindo resposta imediata e a identificação de outras tentativas no mesmo período.

Vale reforçar: a ausência de alertas não é garantia de segurança — as varreduras começaram menos de 24 horas após o patch, então a janela de exploração silenciosa é real. Logs antigos merecem a mesma caçada.

Como se proteger

Atualize o GitLab imediatamente. Esta é a medida única mais importante: instâncias self-managed precisam ir para 19.3.2, 19.2.6 ou 19.1.8 o quanto antes. O GitLab.com (nuvem) já roda a versão corrigida, e clientes GitLab Dedicated não precisam de ação. Atenção ao upgrade: o patch inclui migrações de banco, então instâncias single-node terão uma janela de indisponibilidade durante a atualização; ambientes multi-node podem usar o procedimento de zero-downtime.

Trate o servidor como potencialmente comprometido. Se a instância esteve exposta na internet entre o lançamento do patch e agora — e a maioria dos self-managed está —, revise os logs em busca de POSTs com file.path antes de declarar o problema resolvido. O registro no KEV exige forensic triage para agências federais; o setor privado deveria adotar o mesmo rigor.

Rotine os secrets que podem ter sido lidos. Assuma o pior cenário: rotacione tokens de API, chaves SSH, senhas de banco, certificados e, principalmente, as variáveis secretas de CI/CD armazenadas no GitLab — além do próprio arquivo de segredos da instância. Um secret lido em 12 de setembro continua válido e útil para o atacante até ser trocado; rotação é a única forma de invalidá-lo.

Reduza a superfície de exposição. Instâncias que não precisam ser públicas na internet devem sair da frente do mundo: restrinja o acesso por VPN, rede privada ou regras de firewall, e exija autenticação de rede para qualquer administração. Mesmo corrigida, uma instância exposta continua sendo alvo de outras falhas futuras — o histórico do GitLab no KEV mostra que esta não é a primeira nem será a última.

Conclusão

O CVE-2026-85706 é a combinação mais perigosa que existe em segurança: severidade máxima (CVSS 10.0), exploração trivial — uma requisição HTTP sem autenticação — e alvo que concentra os ativos mais valiosos da empresa: código, credenciais e secrets de deploy. A CISA confirmou a exploração ativa ao incluir a falha no KEV, e a watchTowr observou as varreduras em massa começarem menos de 24 horas após o patch; o prazo de três dias dado às agências federais vence justamente em 14 de setembro.

Para quem administra GitLab self-managed, a sequência correta é: patch imediato, caçada nos logs com a regra da watchTowr e rotação preventiva de secrets. Sem ator nomeado e sem vítimas brasileiras confirmadas até o momento, mas a lição do caso independe disso: quando uma falha máxima em infraestrutura crítica de desenvolvimento fica pública, o tempo entre o disclosure e a exploração indiscriminada se mede em horas.

Perguntas frequentes

Fontes e leituras adicionais

• BleepingComputer — CISA: Hackers now exploit max severity GitLab flaw in attacks — 14/09/2026
• GitLab — GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 — 10/09/2026
• CISA — Known Exploited Vulnerabilities Catalog — 11/09/2026