gitread

CVE-2026-85706 · Leitura de arquivos não autenticada no GitLab CE/EE · PoC de pesquisa com modo oracle, enumeração de fd e coleta em camadas

Como funciona

Três endpoints da API de repositório ficam atrás do requestBodyUploader do Workhorse:

O handler do Rails chama File.open(params['file.path']) antes de authenticate!. Quatro condições tornam isso explorável:

1. A autenticação ocorre depois da leitura do arquivo. require_gitlab_workhorse! apenas verifica o cabeçalho JWT Gitlab-Workhorse-Api-Request. O Workhorse carimba esse cabeçalho em toda requisição que ele faz proxy, incluindo passthroughs simples. O authenticate! real fica dentro de authorize_push_to_branch!, que é executado depois que file_params_from_body_upload já leu o arquivo do disco.

2. file.path vem diretamente da requisição. file_params_from_body_upload lê params['file.path'] como um caminho absoluto sem nenhuma validação. No fluxo pretendido, o Workhorse grava o upload em um arquivo temporário e injeta esse parâmetro por conta própria. Um atacante simplesmente o envia diretamente como parâmetro de query string apontando para qualquer lugar do sistema de arquivos.

3. A correspondência de rotas do Workhorse nunca decodifica percent-encoding. O Workhorse compara rotas de upload com EscapedPath(), os bytes brutos da URL conforme recebidos. O Puma decodifica sequências %XX antes de rotear para o Grape. Assim, codificar um caractere em um segmento estático faz o Workhorse pular sua regra de reescrita enquanto o Rails ainda roteia para o handler vulnerável:

4. O Rack ecoa o conteúdo do arquivo de volta na resposta de erro. Com Content-Type: application/x-www-form-urlencoded, o conteúdo do arquivo é entregue a Rack::Utils.parse_nested_query. Qualquer % isolado não seguido de dois dígitos hexadecimais gera InvalidParameterError: invalid %-encoding (<content>). Tudo até o primeiro & no arquivo é ecoado no corpo da resposta 400.

Arquivos sem % isolado ainda são lidos antes da autenticação. A resposta 401 do ramo urlencoded e um 500 do ramo multipart confirmam que o arquivo existe e é legível pelo usuário git, tornando-os úteis como oráculo de existência.

Requisição de exploit:

Recursos

• --file lê qualquer arquivo único; recorre automaticamente ao oráculo se não houver gatilho de eco
• --loot executa 36 alvos em 7 camadas, ordenados por probabilidade confirmada de gatilho de eco
• --oracle executa uma sondagem de ramo duplo (urlencoded + multipart) contra arquivos sem eco e informa se cada um é legível, ausente ou ilegível
• --proc enumera /proc/self/fd/0-31 para encontrar descritores de arquivo abertos, depois lê alvos padrão de reconhecimento em /proc
• --shell entra em um shell interativo de leitura de arquivos com os comandos cat, loot, oracle, project e curl
• --pipe lê alvos da entrada padrão e trata saída do subfinder, texto do httpx, JSON do httpx, JSON do nuclei e linhas brutas de hosts
• --list recebe um arquivo de alvos, um por linha
• --threads para varredura em massa concorrente
• --proxy roteia tudo através do Burp ou mitmproxy
• --raw grava bytes brutos na saída padrão sem decoração, útil para redirecionar para um arquivo
• --full executa loot, oracle e proc em uma única passada
• Saída de relatório em JSON e JSONL via -o
• Fingerprint de versão do GitLab com verificação de faixa afetada
• Suporte a cores no terminal do Windows

Instalação

Requer Python 3.10 ou mais recente. Nenhuma outra dependência.

Uso

Alvo único

Pipeline

A entrada padrão é detectada automaticamente quando não é um TTY, então --pipe é opcional na maioria dos casos.

Shell

Vereditos de resposta

Camadas de loot

Flags

Códigos de saída: 0 vazamento confirmado, 1 apenas oráculo ou nenhum vazamento no pipeline, 2 nada encontrado.

Correção

Corrigido no commit master 0d9ce3e7, retroportado como 1fe30154 / b43c8b26 / 0ff7b6b2.

Três coisas foram alteradas ao mesmo tempo:

1. authenticate! foi movido para antes de file_params_from_body_upload nos três endpoints, de modo que o arquivo nunca é lido para uma requisição não autenticada
2. file.path agora só é aceito a partir de um objeto UploadedFile tipado, produzido pelo middleware multipart, que exige um JWT válido assinado pelo Workhorse, e não de um parâmetro de query string bruto
3. InvalidParameterError não interpola mais e.message no corpo da resposta, de modo que o canal de eco é fechado mesmo que alguém encontre uma forma de contornar as duas primeiras correções

O bug foi introduzido no GitLab 18.7 (dezembro de 2025), quando a variante de upload de corpo da API de commits foi adicionada.

feito com amor por @plur1bu5 -- se você achar útil, uma estrela é apreciada