guneykabel/cve-2026-85706PoC de exploit em Python para CVE-2026-85706, uma leitura arbitrária de arquivos não autenticada no GitLab CE/EE via bypass de codificação de caminho do Workhorse, com writeup e variantes de bypass.
Leitura arbitrária de arquivos locais sem autenticação no GitLab CE/EE. Afeta 18.7–19.1.7, 19.2.0–19.2.5, 19.3.0–19.3.1. Corrigido em 19.1.8 / 19.2.6 / 19.3.2 (2026-09-10). CVSS 10.0, supostamente explorado em ambiente real. Relatório original de s3ntago e este repositório é apenas o meu writeup + PoC.
Esta PoC é publicada apenas para fins educacionais e de pesquisa defensiva, para ajudar administradores e pesquisadores a entender e testar a vulnerabilidade. Execute-a exclusivamente contra sistemas que você possui ou tem autorização escrita explícita para testar. Se a sua instância está na faixa afetada, pare de ler e aplique o patch para 19.1.8 / 19.2.6 / 19.3.2 primeiro.
Três endpoints de repositório (POST :id/repository/commits, POST/PUT :id/repository/files/:file_path) ficam atrás do requestBodyUploader do Workhorse. O handler do Rails lê o caminho em disco diretamente do campo bruto file.path da requisição e faz File.open nele antes de qualquer autenticação. O não serve como autenticação porque o signing round-tripper do Workhorse anexa um JWT válido a toda requisição que ele faz proxy, então qualquer coisa que caia no proxy genérico da API passa nessa verificação.
require_gitlab_workhorse!Gitlab-Workhorse-Api-RequestA única razão pela qual isso não é LFI instantâneo para todo mundo é que o Workhorse deveria reescrever a requisição primeiro. Mas a regex de rota dele casa contra o caminho escapado (EscapedPath() mais um clone com path.Clean que nunca decodifica %XX), enquanto o Puma decodifica %XX antes do roteamento do Grape. Então basta percent-encodar qualquer caractere de um segmento estático (%63ommits, %72epository, %66iles), adicionar uma barra no final, ou colar um .json que a regex do Workhorse não pega, que o Rails ainda roteia para o handler vulnerável. Essa incompatibilidade de encoding é onde está o bypass. (Variantes como //, /./, %2F, ; não funcionam porque path.Clean normaliza as duas primeiras e o Puma recusa %2F.)
Depois é só enviar metadados de upload forjados e não assinados como query params:
POST /api/v4/projects/1/repository/%63ommits?file=&file.path=<ABSOLUTE_PATH>&file.size=1&Content-Type=application/x-www-form-urlencoded
file= em branco satisfaz a validação requires :file, WorkhorseFile (em branco é coagido para nil). A leitura dispara antes da autenticação. Conseguir os bytes de volta é a parte divertida: no ramo urlencoded o helper executa Rack::Utils.parse_nested_query(File.read(path)) e interpola erros do parser no corpo do 400. Qualquer % não seguido de dois dígitos hexadecimais levanta InvalidParameterError: invalid %-encoding (<raw file bytes>) e o conteúdo do arquivo volta dentro da mensagem de erro. O ramo JSON (Oj) não vaza nada, por isso o content type urlencoded importa aqui.
A correção (master 0d9ce3e7, backports 1fe30154 / b43c8b26 / 0ff7b6b2) adiciona authenticate! aos três endpoints mais o pré-passo /authorize, confia apenas no UploadedFile produzido pelo middleware para path/size, e para de ecoar erros do parser. O bug foi introduzido em dezembro de 2025, por isso a faixa afetada começa em 18.7.
./exploit.py --url http://localhost:8080 --file /etc/hostname
./exploit.py --url http://localhost:8080 --file /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml
O script percorre todas as formas de bypass verificadas (segmentos encodados, barra no final, .json; endpoints commits + files, POST e PUT) e classifica cada resposta para que você possa dizer onde na cadeia uma sondagem morreu. Apenas alvos autorizados, obviamente.
% não seguido de dois caracteres hexadecimais.(.*) até o último ) no corpo). Funciona bem contra o erro JSON padrão, vai capturar demais se algo na frente envolver a resposta em HTML. A correção adequada é fazer o parsing do campo message do JSON.before retorna 404 caso contrário).