CVE-2026-85706: Falha Crítica de Transversal de Caminho no GitLab Explorada em Ambiente Real

O GitLab lançou atualizações de segurança de emergência para uma vulnerabilidade de máxima gravidade nas versões Community Edition (CE) e Enterprise Edition (EE), que permite a atacantes não autenticados ler arquivos arbitrários de servidores vulneráveis. Catalogada como CVE-2026-85706 e classificada com 10.0 na escala CVSS, a falha reside na API de commits de repositório e resulta de confinamento inadequado de caminho combinado com falta de imposição de autenticação.

O risco escalou quase imediatamente após a divulgação. Pesquisadores de segurança observaram uma sondagem em toda a internet começando aproximadamente às 06:00 UTC de 11 de setembro de 2026, pouco depois de o GitLab liberar patches. A CISA subsequentemente adicionou a vulnerabilidade ao seu catálogo de Vulnerabilidades Conhecidas Exploradas com base em evidências de exploração ativa.

A exploração bem-sucedida pode expor arquivos sensíveis armazenados no servidor GitLab, incluindo dados de configuração, credenciais, segredos, logs e outras informações acessíveis ao serviço GitLab. Em ambientes de desenvolvimento, esses arquivos podem conter segredos de CI/CD, credenciais de implantação, tokens, dados relacionados a código-fonte e informações que poderiam apoiar compromissos subsequentes.

A falha é particularmente perigosa para instalações auto-geridas do GitLab expostas à internet porque a exploração não requer uma conta, privilégios existentes ou interação do usuário. De acordo com o watchTowr, o pré-requisito primário para o caminho de ataque observado é que a instância do GitLab contenha pelo menos um projeto público.

Análise do CVE-2026-85706

A vulnerabilidade é um problema de travessia de caminho na API de commits de repositório do GitLab. O GitLab descreve a causa raiz como confinamento insuficiente de caminhos de arquivos combinado com falha em impor a autenticação na funcionalidade afetada. Isso permite que informações de caminho controladas pelo atacante escapem da localização onde o GitLab espera que os arquivos de repositório residam e façam referência a outros arquivos disponíveis para o aplicativo.

O vetor CVSS atribuído pelo GitLab é CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Ele reflete uma vulnerabilidade explorável remotamente com baixa complexidade de ataque, sem necessidade de autenticação e sem interação do usuário. O GitLab atribui impactos de alta confidencialidade e integridade, enquanto a disponibilidade não é diretamente afetada pelo primitivo de leitura de arquivos.

Os detalhes mais importantes para o CVE-2026-85706 são que os atacantes podem interagir remotamente com a API de commits de repositório vulnerável e solicitar caminhos que deveriam ficar fora do diretório permitido de repositório. Se o GitLab falhar em conter corretamente esse caminho, o servidor pode retornar o conteúdo de um arquivo arbitrário acessível ao processo do GitLab.

De acordo com o watchTowr, a exploração pode expor arquivos de configuração e log específicos do GitLab contendo credenciais, segredos e outras informações sensíveis. Dependendo da configuração do sistema e permissões de arquivos, os atacantes também podem mirar em chaves SSH, arquivos de ambiente, credenciais de banco de dados, tokens de implantação ou outros dados de aplicação sensíveis.

O CVE-2026-85706 afeta as seguintes versões do GitLab CE e EE:

• Todas as versões a partir de 18.7 antes de 19.1.8
• Todas as versões a partir de 19.2 antes de 19.2.6
• Todas as versões a partir de 19.3 antes de 19.3.2

O GitLab.com já estava rodando a versão corrigida quando a questão foi divulgada, enquanto os clientes do GitLab Dedicated não precisam tomar uma ação. A exigência urgente de remediação se aplica principalmente a organizações que operam instâncias auto-geridas do GitLab.

A exigência de pelo menos um projeto público aumenta significativamente a exposição de organizações que intencionalmente hospedam repositórios de código aberto, projetos de desenvolvimento público, recursos da comunidade ou outros conteúdos acessíveis anonimamente em sua própria infraestrutura GitLab. Um atacante não precisa de filiação no projeto ou uma conta GitLab válida antes de tentar a exploração.

As consequências podem se estender além da simples divulgação de informações. O GitLab frequentemente se encontra no centro de pipelines de desenvolvimento de software e armazena materiais altamente sensíveis, incluindo código-fonte, variáveis de CI/CD, credenciais de implantação, configuração de infraestrutura, tokens de acesso e segredos de integração.

Se um atacante obtiver tais credenciais por meio de acesso a arquivos arbitrários, a vulnerabilidade inicial do GitLab pode se tornar um trampolim para atividades adicionais de intrusão. Segredos roubados poderiam potencialmente fornecer acesso a repositórios de código-fonte, infraestrutura CI/CD, serviços em nuvem, registros de contêiner, sistemas de implantação ou outros recursos conectados.

Isso também introduz um risco à cadeia de suprimento de software. O acesso a credenciais de desenvolvimento ou infraestrutura de build pode permitir que um atacante tente alterações não autorizadas em repositórios, manipule processos de build, roube código proprietário ou comprometa sistemas downstream que confiam em artefatos produzidos através do ambiente GitLab afetado.

O GitLab creditou o pesquisador de segurança s3ntago por reportar a vulnerabilidade por meio do programa de recompensa de bugs HackerOne da empresa. A data exata de descoberta e relatório privado não foi divulgada publicamente. O GitLab lançou versões corrigidas em 10 de setembro de 2026 e documentou publicamente a falha como parte de seu lançamento de patch crítico.

A transição da divulgação para atividade hostil foi extremamente rápida. WatchTowr disse que sua rede de honeypot Attacker Eye detectou sondas comportamentais direcionando a vulnerabilidade a partir de aproximadamente 06:00 UTC em 11 de setembro, indicando que atores externos já haviam engenharia reversa da fraqueza e começaram a testar sistemas GitLab acessíveis pela internet.

A CISA adicionou a falha ao seu catálogo KEV mais tarde em 11 de setembro após confirmar evidências de exploração ativa. As agências do ramo executivo civil federal foram instruídas a remediar sistemas afetados até 14 de setembro de 2026, e a CISA também marcou a vulnerabilidade como exigindo triagem forense sob a Diretriz Operacional Vinculativa 26-04.

Código PoC público do CVE-2026-85706 também apareceu logo após a divulgação, reduzindo ainda mais a barreira técnica para atacantes interessados em reproduzir o comportamento de leitura de arquivos arbitrários. Combinado com a baixa complexidade da vulnerabilidade e o caminho de ataque não autenticado, a reprodução pública aumenta a probabilidade de exploração oportunista mais ampla.

Atualmente não há um conjunto abrangente de IOCs específicos à campanha CVE-2026-85706, como endereços IP de atacantes, domínios ou hashes de malware que possam identificar de forma confiável a exploração. Em vez disso, o indicador mais útil é a estrutura de solicitações direcionadas à API GitLab vulnerável.

O WatchTowr recomenda procurar por solicitações HTTP POST direcionadas a caminhos compatíveis com:

/api/v4/projects/{id}/repository/commits/

Os defensores devem prestar atenção especial quando essas solicitações contêm parâmetros de caminho de arquivo suspeitos ou parecem solicitar arquivos não relacionados ao repositório que está sendo acessado.

Mitigação do CVE-2026-85706

O GitLab recomenda fortemente que todas as instalações auto-geridas afetadas atualizem imediatamente para um dos lançamentos corrigidos:

• GitLab 19.1.8
• GitLab 19.2.6
• GitLab 19.3.2

Qualquer lançamento posterior compatível que contenha a correção de segurança também deve resolver a vulnerabilidade. Os administradores devem verificar a versão exata em execução em vez de assumir que a atualização automática ocorreu.

Organizações incapazes de aplicar patch imediatamente devem remover o acesso público desnecessário à instância do GitLab afetada ou restringir a conectividade no proxy reverso, firewall, balanceador de carga ou a camada de rede até que a atualização possa ser concluída. Isso é apenas uma medida temporária de redução de exposição e não deve substituir a instalação da versão corrigida do GitLab.

A detecção do CVE-2026-85706 deve começar com a identificação de todas as instâncias auto-geridas do GitLab, suas versões exatas e se estavam acessíveis pela internet após 10 de setembro. Sistemas que hospedam um ou mais projetos públicos devem receber prioridade particularmente alta na investigação.

Para detectar exploração ou reconhecimento do CVE-2026-85706, os defensores devem revisar a telemetria do GitLab, proxy reverso, WAF e servidor web para:

• Solicitações HTTP POST para /api/v4/projects/{id}/repository/commits/
• Solicitações contendo parâmetros de caminho de arquivo incomuns
• Sequências de travessia de caminho tentando sair dos diretórios de repositório esperados
• Solicitações de arquivos de configuração ou log do GitLab através das APIs de repositório
• Um grande número de solicitações API de commits de repositório de fontes previamente desconhecidas
• Acesso anônimo seguido de tentativas incomuns de recuperar recursos do lado do servidor
• Acesso inesperado a credenciais, arquivos de configuração ou segredos de aplicação
• Nova atividade de autenticação usando credenciais que podem ter sido expostas através do GitLab
• Acesso não explicado a CI/CD, cloud, registro ou infraestrutura de implantação após atividade suspeita do GitLab

O WatchTowr recomenda especificamente revisar o padrão da API de commits de repositório porque ele pode fornecer evidência direta de sondas ou tentativas de exploração contra o endpoint vulnerável.

O patch também deve ser combinado com investigação retrospectiva. A exigência da CISA para triagem forense reflete a possibilidade de que organizações possam ter sido comprometidas antes de implantar a correção, particularmente dado o quão rapidamente os ataques começaram após a divulgação.

Se atividade suspeita de leitura de arquivos for identificada, os administradores devem determinar exatamente quais arquivos podem ter sido acessados. Segredos contidos em arquivos potencialmente expostos devem ser considerados comprometidos até que se prove o contrário.

As organizações devem considerar rotacionar:

• Tokens de acesso e pessoais do GitLab
• Tokens de implantação
• Variáveis e segredos de CI/CD
• Credenciais de banco de dados
• Chaves SSH
• Credenciais em nuvem
• Credenciais de registro de contêiner
• Tokens de API e integração
• Segredos OAuth
• Credenciais de implantação e automação

As equipes de segurança também devem investigar sistemas downstream que confiavam nessas credenciais. Atualizar o GitLab fecha o caminho vulnerável de leitura de arquivos, mas não pode invalidar segredos já obtidos por um atacante.

Para sistemas de alto risco, os defensores devem comparar a atividade recente de repositório, pipeline, conta, runner e implantação com registros conhecidos bons para identificar possíveis abusos subsequentes. Modificações inesperadas de pipeline, mudanças de repositório, tokens recém-emitidos ou acessos incomuns à infraestrutura de build devem ser investigados.

Dada a severidade CVSS 10.0, exploração confirmada, reprodução pública e rápida transição de divulgação para escaneamento, a remediação deve ser tratada como uma emergência para implantações auto-geridas do GitLab voltadas para a internet.