Prérequis

• Docker + docker compose, python3, git, curl sur la machine hôte.
• ~8 Go de RAM libre (deux instances GitLab, ~4 Go chacune) et ~10 Go de disque. Premier démarrage : 4–8 min/instance.
• À exécuter uniquement contre ces instances lab locales. Tests autorisés/défensifs d'un logiciel que vous contrôlez.

Exécution

Résultat attendu :

Autres sous-commandes :

Comment fonctionne l'oracle (pas de triche avec le HTTP-200)

Les serveurs vulnérable et corrigé répondent tous deux à la publication malveillante par HTTP 200 {"status":"processing"} — le fichier est écrit plus tard, dans le worker de finalisation. Le statut HTTP n'est donc pas un oracle. exploit/poc.py --verify-docker <container> interroge à la place, à l'intérieur du conteneur, l'apparition du fichier contrôlé au chemin traversé et compare son SHA-1 :

• vulnérable → /var/tmp/CVE_2026_10053_PROOF-1.0.0.tgz apparaît (propriétaire git:git, nos octets) → code de sortie 0.
• corrigé → le fichier n'apparaît jamais ; le worker journalise Gitlab::PathTraversal::PathTraversalAttackError: Invalid path → code de sortie 2.

L'exploit lui-même n'est rien d'autre que la requête authentifiée PUT …/packages/npm/:pkg ; le path traversal réside entièrement dans le corps JSON name (file_name = "#{name}-#{version}.tgz", uniquement contrôlé non vide). Les appels docker exec relèvent de la vérification et de la mise en place, jamais de la capacité de l'attaquant.

Portée

• Prouvé : un utilisateur authentifié (Developer+ peut publier des paquets ; ce laboratoire utilise un PAT root pour la commodité de la mise en place) écrit des octets contrôlés par l'attaquant sur n'importe quel chemin accessible en écriture par git. Les fichiers sont créés en 0644.
• Non prouvé ici : la RCE. Le nom de fichier stocké est contraint de se terminer par -<semver>.tgz (le NUL est rejeté par le noyau, le retour à la ligne ne tronque pas), donc aucune cible à nom exact (secrets.yml, authorized_keys, un .rb, binaires gitaly) ne peut être écrasée. Le seul exécuteur indépendant du nom, custom_hooks/<hook>.d/, exécute n'importe quel nom de fichier mais seulement s'il est exécutable — et cette écriture est en 0644. Écraser un fichier 0755 préexistant n'aide pas : le store remplace l'inode et le réinitialise à 0644. La RCE nécessite donc une primitive distincte de bit exécutable / d'exécution que ce PoC ne fournit pas.

./run.sh rce-gate démontre exactement cela de manière honnête : il place un hook pre-receive.d via le path traversal, pousse, et montre que le hook 0644 ne s'exécute pas. ./rce_gate_demo.sh --illustrate-gate définit en plus +x via docker exec chmod (une action docker-root hors bande, pas une capacité de l'attaquant) uniquement pour montrer que gitaly l'exécuterait — soulignant que le levier manquant est le bit exécutable.

Cause racine et correctif

Voir ANALYSIS.md pour l'analyse complète. En bref : app/uploaders/gitlab_uploader.rb ne validait le chemin de stockage que before :cache ; au before :store, le file_name dérivé du modèle (contrôlé par l'attaquant, non validé) était écrit tel quel. Le correctif ajoute before :store, :protect_from_path_traversal!.

Fichiers