Requisitos

• Docker + docker compose, python3, git, curl en el host.
• ~8 GB de RAM libre (dos instancias de GitLab, ~4 GB cada una) y ~10 GB de disco. Primer arranque: 4–8 min/instancia.
• Ejecutar solo contra estas instancias de laboratorio locales. Pruebas autorizadas/defensivas de software que usted controla.

Ejecución

Resultado esperado:

Otros subcomandos:

Cómo funciona el oráculo (sin hacer trampa con HTTP-200)

Tanto el servidor vulnerable como el parcheado responden a la publicación maliciosa con HTTP 200 {"status":"processing"} — el archivo se escribe más tarde, en el worker de finalización. Por lo tanto, el estado HTTP no es un oráculo. exploit/poc.py --verify-docker <container> en su lugar consulta dentro del contenedor la presencia del archivo controlado en la ruta atravesada y compara su SHA-1:

• vulnerable → /var/tmp/CVE_2026_10053_PROOF-1.0.0.tgz aparece (propietario git:git, nuestros bytes) → exit 0.
• parcheado → el archivo nunca aparece; el worker registra Gitlab::PathTraversal::PathTraversalAttackError: Invalid path → exit 2.

El exploit en sí no es más que la solicitud autenticada PUT …/packages/npm/:pkg; el traversal reside por completo en el cuerpo JSON name (file_name = "#{name}-#{version}.tgz", solo se comprueba que no esté vacío). Las llamadas a docker exec son verificación y configuración, nunca parte de la capacidad del atacante.

Alcance

• Demostrado: un usuario autenticado (Developer+ puede publicar paquetes; este laboratorio usa un PAT de root por comodidad de configuración) escribe bytes controlados por el atacante en cualquier ruta escribible por git. Los archivos quedan con permisos 0644.
• No demostrado aquí: RCE. El nombre base almacenado se ve forzado a terminar en -<semver>.tgz (el kernel rechaza el NUL, el salto de línea no trunca), por lo que no se puede sobrescribir ningún objetivo con nombre exacto (secrets.yml, authorized_keys, un .rb, binarios de gitaly). El único ejecutor independiente del nombre de archivo, custom_hooks/<hook>.d/, ejecuta cualquier nombre de archivo pero solo si es ejecutable — y esta escritura es 0644. Sobrescribir un archivo 0755 preexistente no ayuda: el store reemplaza el inodo, restableciéndolo a 0644. Por lo tanto, RCE necesita una primitiva separada de bit ejecutable / ejecución que este PoC no proporciona.

./run.sh rce-gate demuestra exactamente esto de forma honesta: planta un hook pre-receive.d mediante el traversal, hace push, y muestra que el hook 0644 no se ejecuta. ./rce_gate_demo.sh --illustrate-gate además establece +x mediante docker exec chmod (una acción docker-root fuera de banda, no una capacidad del atacante) únicamente para mostrar que gitaly sí lo ejecutaría — lo que subraya que la palanca que falta es el bit de ejecución.

Causa raíz y corrección

Consulte ANALYSIS.md para ver el análisis completo. En resumen: app/uploaders/gitlab_uploader.rb validaba la ruta de almacenamiento solo con before :cache; en before :store, el file_name derivado del modelo (controlado por el atacante, sin validar) se escribía tal cual. La corrección añade before :store, :protect_from_path_traversal!.

Archivos