gitread

CVE-2026-85706 · Lecture de fichiers non authentifiée dans GitLab CE/EE · PoC de recherche avec mode oracle, énumération de descripteurs de fichiers et ciblage de butin par niveaux

Fonctionnement

Trois endpoints de l'API repository se trouvent derrière le requestBodyUploader de Workhorse :

Le handler Rails appelle File.open(params['file.path']) avant authenticate!. Quatre conditions rendent cela exploitable :

1. L'authentification se déclenche après la lecture du fichier. require_gitlab_workhorse! ne vérifie que l'en-tête JWT Gitlab-Workhorse-Api-Request. Workhorse appose cet en-tête sur chaque requête qu'il proxifie, y compris les simples passthroughs. Le véritable authenticate! se trouve à l'intérieur de authorize_push_to_branch!, qui s'exécute après que file_params_from_body_upload a déjà lu le fichier sur le disque.

2. file.path provient directement de la requête. file_params_from_body_upload lit params['file.path'] comme un chemin absolu sans aucune validation. Dans le flux prévu, Workhorse écrit l'upload dans un fichier temporaire et injecte lui-même ce paramètre. Un attaquant l'envoie simplement directement comme paramètre de query string pointant n'importe où sur le système de fichiers.

3. Le matching de routes de Workhorse ne décode jamais le percent-encoding. Workhorse fait correspondre les routes d'upload avec EscapedPath(), les octets bruts de l'URL tels que reçus. Puma décode les séquences %XX avant le routage vers Grape. Ainsi, encoder un caractère dans un segment statique fait que Workhorse saute sa règle de réécriture tandis que Rails route toujours vers le handler vulnérable :

4. Rack renvoie le contenu du fichier dans la réponse d'erreur. Avec Content-Type: application/x-www-form-urlencoded, le contenu du fichier est transmis à Rack::Utils.parse_nested_query. Tout % nu non suivi de deux chiffres hexadécimaux déclenche InvalidParameterError: invalid %-encoding (<content>). Tout ce qui précède le premier & dans le fichier est renvoyé dans le corps de la réponse 400.

Les fichiers sans % nu sont tout de même lus avant authentification. La réponse 401 de la branche urlencoded et la 500 de la branche multipart confirment toutes deux que le fichier existe et est lisible par l'utilisateur git, ce qui les rend utiles comme oracle d'existence.

Requête d'exploit :

Fonctionnalités

• --file lit n'importe quel fichier unique ; bascule automatiquement vers l'oracle s'il n'y a pas de déclencheur d'écho
• --loot exécute 36 cibles réparties sur 7 niveaux, ordonnées par probabilité confirmée de déclencheur d'écho
• --oracle exécute une sonde à double branche (urlencoded + multipart) contre les fichiers sans écho et indique si chacun est lisible, manquant ou illisible
• --proc énumère /proc/self/fd/0-31 pour trouver les descripteurs de fichiers ouverts, puis lit les cibles de reconnaissance /proc standard
• --shell ouvre un shell interactif de lecture de fichiers avec les commandes cat, loot, oracle, project et curl
• --pipe lit les cibles depuis stdin et gère la sortie subfinder, le texte httpx, le JSON httpx, le JSON nuclei et les lignes d'hôtes brutes
• --list prend un fichier de cibles, une par ligne
• --threads pour le scan en masse concurrent
• --proxy route tout via Burp ou mitmproxy
• --raw écrit les octets bruts sur stdout sans décoration, utile pour rediriger vers un fichier
• --full exécute loot, oracle et proc en une seule passe
• Sortie de rapport JSON et JSONL via -o
• Empreinte de version GitLab avec vérification de la plage affectée
• Prise en charge des couleurs du terminal Windows

Installation

Nécessite Python 3.10 ou plus récent. Aucune autre dépendance.

Utilisation

Cible unique

Pipeline

stdin est détecté automatiquement lorsqu'il ne s'agit pas d'un TTY, donc --pipe est optionnel dans la plupart des cas.

Shell

Verdicts de réponse

Niveaux de loot

Options

Codes de sortie : 0 fuite confirmée, 1 oracle uniquement ou aucune fuite en pipeline, 2 rien trouvé.

Correctif

Corrigé dans le commit master 0d9ce3e7, rétroporté sous 1fe30154 / b43c8b26 / 0ff7b6b2.

Trois choses ont été modifiées en même temps :

1. authenticate! a été déplacé avant file_params_from_body_upload dans les trois endpoints afin que le fichier ne soit jamais lu pour une requête non authentifiée
2. file.path n'est désormais accepté que depuis un objet UploadedFile typé produit par le middleware multipart, ce qui nécessite un JWT valide signé par Workhorse, et non depuis un paramètre de query string brut
3. InvalidParameterError n'interpole plus e.message dans le corps de la réponse, fermant ainsi le canal d'écho même si quelqu'un trouvait un moyen de contourner les deux premiers correctifs

Le bug a été introduit dans GitLab 18.7 (décembre 2025) lorsque la variante body-upload de l'API commits a été ajoutée.

fait avec amour par @plur1bu5 -- si vous le trouvez utile, une étoile est appréciée