CVSS 10 no GitLab — Leitura Arbitrária de Arquivos Sem Autenticação na API de Commits¶

Data da divulgação: 10 de setembro de 2026 Corrigido por: GitLab (fonte da descoberta não especificada nas fontes consultadas) Severidade: Crítica (CVSS até 10.0) Status: Sondagens ativas confirmadas desde 06:00 UTC de 11/09/2026 Report por: Willian Hirata

Resumo¶

O GitLab corrigiu duas vulnerabilidades críticas na mesma release: CVE-2026-85706 (CVSS 10.0), um path traversal na API de commits do repositório que permite a um atacante sem qualquer credencial ler arquivos arbitrários do servidor, e CVE-2026-87719 (CVSS 9.9), uma desserialização insegura no GitLab Enterprise Edition que expõe configurações e credenciais para usuários autenticados com acesso ao Duo Chat.

A primeira já está sob sondagem ativa: segundo a watchTowr, atacantes começaram a testar o endpoint vulnerável a partir de 06:00 UTC de 11 de setembro de 2026 — poucas horas depois do lançamento do patch. É a segunda vulnerabilidade crítica do GitLab em poucas semanas: em agosto, o CVE-2026-19478 (injeção de código via GraphQL) já havia sido explorado quase imediatamente após a divulgação.

Linha do Tempo¶

Data	Evento
10/09/2026	GitLab lança as versões 19.3.2, 19.2.6 e 19.1.8, corrigindo o CVE-2026-85706 e o CVE-2026-87719
11/09/2026, ~06:00 UTC	watchTowr identifica o início de sondagens ativas contra o endpoint vulnerável da API de commits
11/09/2026	watchTowr publica o alerta "Rapid Reaction"; The Hacker News publica cobertura do caso com comentário de Jake Knott, head of threat intelligence da watchTowr

As Duas Vulnerabilidades Corrigidas¶

Diferente do caso MikroTrick, aqui não há uma cadeia de exploração combinando as duas falhas — são dois problemas críticos distintos, corrigidos na mesma release, que afetam partes diferentes do GitLab. Vale a pena entender os dois, porque o segundo pode passar despercebido diante da nota máxima do primeiro.

CVE	Severidade	Resumo
CVE-2026-85706	Crítica (CVSS 10.0)	Leitura arbitrária de arquivos, sem autenticação, via API de commits do repositório
CVE-2026-87719	Crítica (CVSS 9.9)	Desserialização insegura no GitLab EE, explorável por usuário autenticado com acesso ao Duo Chat

Nota: até a publicação deste relatório, não localizei os registros CVE/NVD completos com CWE oficial e vetor CVSS para as duas falhas — as informações abaixo vêm das notas de segurança do próprio GitLab e da análise técnica da watchTowr.

CVE-2026-85706 — Leitura arbitrária de arquivos via API de commits¶

A API de commits do repositório do GitLab aceita um parâmetro de caminho de arquivo para operações sobre um commit específico. Segundo o próprio GitLab, a causa raiz combina dois problemas ao mesmo tempo: o confinamento de caminho — que deveria impedir que esse parâmetro escapasse do diretório esperado — não foi aplicado corretamente, e o endpoint não exigia autenticação nenhuma.

Com os dois problemas juntos, um atacante sem qualquer credencial pode montar uma requisição informando um caminho de arquivo arbitrário e receber de volta o conteúdo desse arquivo no servidor — incluindo, potencialmente, arquivos de log e de configuração fora do repositório, que podem conter credenciais e segredos. Segundo a watchTowr, a única pré-condição para a exploração é que a instância tenha ao menos um projeto público, o que torna o ataque simples de automatizar em escala.

CVE-2026-87719 — Desserialização insegura no GitLab EE¶

Este segundo problema afeta apenas o GitLab Enterprise Edition e depende de autenticação prévia. Segundo o GitLab, um usuário autenticado com acesso ao recurso Duo Chat pode enviar um argumento especialmente construído em uma subscription GraphQL para contornar a serialização esperada pela aplicação e forçar uma busca de objeto diretamente no servidor. Isso permite obter configurações da instância de Advanced Search e credenciais sensíveis associadas — informações que esse usuário não deveria conseguir acessar diretamente.

É uma falha menos "chamativa" que a primeira por exigir autenticação, mas ilustra um vetor de risco diferente: o de um usuário legítimo, com acesso a um recurso aparentemente inofensivo, conseguindo escalar para informações que só deveriam estar disponíveis a administradores.

Indicadores de Comprometimento (IoCs)¶

Padrão de log a monitorar (segundo a recomendação da watchTowr):

Requisições HTTP POST para URIs no formato /api/v4/projects/{id}/repository/commits/...
contendo um parâmetro "file.Path" (conforme grafado pela própria watchTowr)

O que ainda não foi divulgado publicamente — diferente do caso MikroTrick, que teve IPs de atacantes e hashes de arquivos confirmados, nas fontes consultadas para este relatório não há:

IPs de origem das sondagens observadas pela watchTowr
Hashes de ferramentas ou scripts usados nos testes
Confirmação pública de leitura de arquivo ou exfiltração bem-sucedida — as fontes falam em "sondagens" (probes), não em comprometimento confirmado, até a publicação deste relatório

A ausência de IOCs mais específicos não significa ausência de risco. Significa que a fase de exploração observada até agora é de reconhecimento e teste, e que a corrida entre a aplicação do patch e uma eventual exploração em massa ainda está em andamento.

Como Verificar se uma Instância foi Afetada¶

Liste todas as instâncias GitLab self-managed (CE/EE) do ambiente e confirme a versão exata em uso.
Confira se a versão está em uma das faixas afetadas: 18.7 até anterior a 19.1.8; 19.2 até anterior a 19.2.6; ou 19.3 até anterior a 19.3.2.
Verifique se a instância tem ao menos um projeto público — segundo a watchTowr, essa é a única pré-condição para a exploração do CVE-2026-85706.
Revise os logs de acesso à API de commits em busca do padrão de requisição descrito na seção de IoCs, inclusive de origens não autenticadas.
Para o CVE-2026-87719, levante quais contas têm acesso ao recurso Duo Chat, já que a exploração exige autenticação e esse acesso específico.
Confirme se a organização usa GitLab.com ou GitLab Dedicated — nesses casos, segundo o próprio GitLab, nenhuma ação adicional é necessária.

Um Padrão Recorrente: Segunda Crítica do GitLab em Poucas Semanas¶

Jake Knott, head of threat intelligence da watchTowr, chamou atenção para o fato de que esta é a segunda vulnerabilidade de severidade crítica no GitLab em semanas recentes. A anterior foi o CVE-2026-19478, uma injeção de código via GraphQL divulgada em agosto de 2026, que também passou a ser explorada quase imediatamente após a divulgação.

Segundo Knott, o apelo do GitLab como alvo é evidente: uma instância comprometida dá acesso a código-fonte, segredos de CI/CD e credenciais, além de abrir caminho para injetar código em pipelines de build — comprometendo não só o GitLab, mas tudo o que depende dele mais adiante na cadeia de build e deploy. Com base no histórico recente de exploração rápida de falhas críticas no GitLab, ele avalia que a transição desta falha para uma exploração em massa e indiscriminada provavelmente não está longe, e que o tempo de reação dos defensores é limitado.

Recomendações¶

Faixa afetada	Versão corrigida
18.7 até anterior a 19.1.8	19.1.8
19.2 até anterior a 19.2.6	19.2.6
19.3 até anterior a 19.3.2	19.3.2

GitLab.com já está na versão corrigida, e clientes GitLab Dedicated não precisam agir. O foco de risco está inteiramente em instâncias self-managed expostas à internet.

Se a atualização não puder ser aplicada imediatamente:

Restrinja ou remova temporariamente projetos públicos da instância, já que essa é a pré-condição citada pela watchTowr para a exploração do CVE-2026-85706.
Limite o acesso externo à instância a redes de gerência confiáveis (VPN, allowlist de IPs) até a atualização.
Revise quem tem acesso ao Duo Chat, reduzindo a superfície de exposição ao CVE-2026-87719.
Essas são mitigações temporárias — não substituem a atualização.

Se houver indício de sondagem ou comprometimento:

Revise os logs de acesso à API de commits no período de exposição, usando o padrão descrito na seção de IoCs.
Troque proativamente credenciais, chaves SSH e segredos de CI/CD que possam estar em arquivos de configuração ou log acessíveis pela falha.
Audite pipelines de CI/CD em busca de alterações não autorizadas — a injeção de código em pipelines é um dos riscos citados pela watchTowr.
Documente o incidente internamente, mesmo que a sondagem pareça ter sido apenas um teste automatizado.

Por Que Isso Importa (Blue Team)¶

Esse caso reforça um princípio que já apareceu no relatório do MikroTrick: a publicação de um patch não é o fim do risco, é o início de uma corrida. Assim que a correção fica pública, um atacante pode comparar o código antes e depois da mudança e reconstruir os detalhes exatos da falha — foi exatamente isso que se observou aqui, com sondagens registradas poucas horas depois do lançamento das versões corrigidas.

Vale reforçar também um princípio simples de Defesa em Profundidade: uma instância GitLab exposta à internet sem necessidade real já é, por si só, um risco — restringir o acesso público quando a exposição externa não é indispensável seria uma mitigação eficaz mesmo antes de qualquer CVE específico existir. Por fim, o CVE-2026-87719 é um lembrete de que nem toda falha crítica exige um atacante "de fora": um usuário autenticado com acesso a um recurso aparentemente inofensivo também pode ser um vetor, o que reforça a importância do Princípio do Menor Privilégio na hora de conceder acesso a funcionalidades de IA integradas a plataformas de desenvolvimento.