Versões Afetadas

Análise Técnica

Contexto da Arquitetura

O GitLab opera com três camadas de processamento HTTP:

O Workhorse é um proxy reverso inteligente: para certos endpoints de "upload" (commits de repositório, operações em arquivos), ele lê o corpo da requisição multipart, salva os dados em disco e reescreve a requisição antes de encaminhá-la ao Puma. Crucialmente, ele anexa um cabeçalho JWT (Gitlab-Workhorse-Api-Request) a cada requisição que intermedia. O Rails então valida esse JWT (via require_gitlab_workhorse!) antes de executar qualquer lógica do handler.

Causa Raiz — Incompatibilidade de Decodificação de Caminho entre 3 Camadas

Camada 1 — Correspondência de rotas no Workhorse:
O Workhorse combina caminhos de requisição usando uma regex compilada que opera sobre a string de bytes bruta, codificada em percent-encoding. Ele não decodifica sequências %XX antes de fazer a correspondência.

Camada 2 — Roteamento Puma/Rack:
O Puma decodifica sequências %XX antes do Grape rotear a requisição. Portanto, uma requisição para /repository/%63ommits é decodificada para /repository/commits e roteada para CommitsController.

Camada 3 — Leitura de arquivo pré-autenticação:
Uma vez no handler do Rails (alcançado sem o JWT do Workhorse, pois o Workhorse nunca correspondeu à requisição), o handler lê params[:file][:path] da query string e chama:

O Truque do Bypass

Ao codificar em percent-encoding um único caractere em um segmento estático do caminho, a requisição do atacante passa despercebida pelo Workhorse:

Mecanismo de Exfiltração de Conteúdo

Após o arquivo ser aberto, o conteúdo é exfiltrado via o parser de query string do Rack:

Se o arquivo contém um % não seguido de dois dígitos hexadecimais válidos (comum em arquivos de configuração Ruby, YAML de CI, logs, etc.), o Rack lança:

Esse corpo de resposta 400 contém os bytes brutos do arquivo até o byte ofensivo — revelando o conteúdo do arquivo ao chamador não autenticado.

Arquivos sem sequências % exploráveis (ex.: /etc/passwd limpo) retornam um 401 ou erro de validação de parâmetro após a leitura: isso age como um oráculo de existência de arquivo (a leitura ainda aconteceu pré-autenticação).

Estrutura da Requisição de Exploit

Mapeamento MITRE ATT&CK

Instalação

Dependências

Uso

Modo rápido vs. completo

Pipeline do modo rápido:

1. GET /api/v4/version — acessibilidade + detecção de GitLab
2. Para cada um dos 4 forms Files API: probe em /etc/hostname + canary único
3. canary → 'local file not present' ∧ hostname ≠ canary → VULNERÁVEL (sai imediatamente)
4. Todos os forms esgotados sem differential → NÃO VULNERÁVEL

Pipeline completo (--full):

1. Detecção do GitLab + fingerprinting de versão
2. Probe de controle (baseline do Workhorse)
3. Todos os 22 forms × caminho canary
4. Confirmação differential com o melhor form confirmado

--project-id nos modos de verificação

A flag --project-id funciona em todos os modos, incluindo --check e --check-host-list. A interação é a seguinte:

Orientação prática:

• --check (rápido): usa apenas forms Files API → project ID irrelevante.
• --check --full: testa todos os 22 forms. Se souber um projeto público, passe --project-id <N> para confirmar também os forms Commits API.
• --check-host-list: um único ID raramente corresponde a um projeto público em todos os hosts. Omita.

Exemplos Práticos

Significado dos Vereditos

Melhorias em Relação ao PoC Python Original

Remediação

1. Aplicar o patch imediatamente: Atualizar para GitLab 19.1.8, 19.2.6 ou 19.3.2.
2. Mitigação imediata: Restringir o acesso público à instância GitLab via controles de rede.
3. Rotação de credenciais: Após o patch, rotacionar todos os segredos que possam ter sido expostos:
   • secret_key_base e otp_key_base em gitlab.rb
   • Senhas de banco de dados
   • Chaves SSH (/home/git/.ssh/, /root/.ssh/)
   • Variáveis CI/CD e tokens de registro de runner
   • Deploy tokens e personal access tokens

Detecção

Buscar nos logs requisições POST ou PUT para caminhos /api/v4/projects/*/repository/ contendo:

• Segmentos estáticos codificados em percent (%63, %43, %72, %70, %66, %46, etc.)
• Parâmetro de query file.path
• Barra final ou sufixo .json nos endpoints commits ou files

Referências

• Registro CVE — cve.org
• GitLab Patch Release 19.3.2
• The Hacker News — Cobertura CVSS 10
• Forkast News — Análise técnica detalhada
• Security Affairs — Exploração ativa
• PoC Python — guneykabel
• MITRE T1083 — Descoberta de Arquivos e Diretórios
• MITRE T1552.001 — Credenciais em Arquivos

Aviso Legal

Esta ferramenta é disponibilizada estritamente para:

• Engagements de teste de penetração autorizados (autorização escrita obrigatória)
• Operações de Red Team dentro do escopo contratado
• Pesquisa de segurança em ambientes de laboratório controlados e isolados
• Competições CTF (Capture The Flag)
• Fins defensivos: compreender a vulnerabilidade para detectá-la/mitigá-la

O uso não autorizado contra sistemas que você não possui ou para os quais não tem autorização escrita explícita para testar é ilegal em praticamente todas as jurisdições e pode resultar em processo criminal conforme leis de crimes de informática (Lei nº 12.737/2012 — "Lei Carolina Dieckmann", LGPD, CFAA, Computer Misuse Act, etc.).

O autor e contribuidores desta ferramenta não assumem qualquer responsabilidade por uso indevido ou danos causados por este software.

Créditos

• PoC Python original: guneykabel — prova de conceito inicial que demonstrou a técnica central de bypass
• Atribuição CVE e divulgação: Time de Segurança do GitLab
• Este PoC Perl: Motor de detecção multi-form expandido, extração de credenciais, varredura em massa, saída JSON para pipelines e lógica de confirmação diferencial