Requisitos

• Docker + docker compose, python3, git, curl no host.
• ~8 GB de RAM livres (duas instâncias do GitLab, ~4 GB cada) e ~10 GB de disco. Primeira inicialização: 4–8 min/instância.
• Execute apenas contra estas instâncias locais do laboratório. Teste autorizado/defensivo de software sob seu controle.

Executar

Resultado esperado:

Outros subcomandos:

Como o oráculo funciona (sem trapacear com HTTP-200)

Tanto o servidor vulnerável quanto o corrigido respondem à publicação maliciosa com HTTP 200 {"status":"processing"} — o arquivo é gravado depois, no worker finalize. Portanto, o status HTTP não é um oráculo. exploit/poc.py --verify-docker <container> em vez disso faz polling dentro do contêiner pelo arquivo controlado no caminho atravessado e compara seu SHA-1:

• vulnerável → /var/tmp/CVE_2026_10053_PROOF-1.0.0.tgz aparece (dono git:git, nossos bytes) → exit 0.
• corrigido → o arquivo nunca aparece; o worker registra Gitlab::PathTraversal::PathTraversalAttackError: Invalid path → exit 2.

O exploit em si nada mais é do que a requisição autenticada PUT …/packages/npm/:pkg; o traversal vive inteiramente no campo name do corpo JSON (file_name = "#{name}-#{version}.tgz", somente verificado se está em branco). As chamadas docker exec são de verificação e configuração, nunca parte da capacidade do atacante.

Escopo

• Provado: um usuário autenticado (Developer+ pode publicar pacotes; este laboratório usa um PAT de root por conveniência de configuração) grava bytes controlados pelo atacante em qualquer caminho gravável por git. Os arquivos ficam com 0644.
• Não provado aqui: RCE. O nome base armazenado é forçado a terminar com -<semver>.tgz (NUL é rejeitado pelo kernel, quebra de linha não trunca), então nenhum alvo de nome exato (secrets.yml, authorized_keys, um .rb, binários do gitaly) pode ser sobrescrito. O único executor que não depende do nome do arquivo, custom_hooks/<hook>.d/, executa qualquer nome de arquivo mas somente se for executável — e esta gravação é 0644. Sobrescrever um arquivo 0755 preexistente não ajuda: o store substitui o inode, redefinindo-o para 0644. Então RCE exige uma primitiva separada de bit de execução / execução que este PoC não fornece.

./run.sh rce-gate demonstra exatamente isso de forma honesta: planta um hook pre-receive.d via o traversal, faz push e mostra que o hook 0644 não executa. ./rce_gate_demo.sh --illustrate-gate adicionalmente define +x via docker exec chmod (uma ação docker-root fora de banda, não uma capacidade do atacante) apenas para mostrar que o gitaly executaria — reforçando que a alavanca que falta é o bit de execução.

Causa raiz e correção

Veja ANALYSIS.md para a análise completa. Em resumo: app/uploaders/gitlab_uploader.rb validava o caminho de armazenamento apenas before :cache; em before :store, o file_name derivado do modelo (controlado pelo atacante, não validado) era gravado literalmente. A correção adiciona before :store, :protect_from_path_traversal!.

Arquivos