gitread

CVE-2026-85706 · lectura de archivos sin autenticación en GitLab CE/EE · PoC de investigación con modo oracle, enumeración de fd y objetivo de loot por niveles

Cómo funciona

Tres endpoints de la API de repositorio se encuentran detrás del requestBodyUploader de Workhorse:

El handler de Rails llama a File.open(params['file.path']) antes de authenticate!. Cuatro condiciones hacen que esto sea explotable:

1. La autenticación se ejecuta después de la lectura del archivo. require_gitlab_workhorse! solo verifica el encabezado JWT Gitlab-Workhorse-Api-Request. Workhorse estampa ese encabezado en cada solicitud que proxea, incluyendo passthroughs simples. El authenticate! real vive dentro de authorize_push_to_branch!, que se ejecuta después de que file_params_from_body_upload ya haya leído el archivo del disco.

2. file.path proviene directamente de la solicitud. file_params_from_body_upload lee params['file.path'] como una ruta absoluta sin validación. En el flujo previsto, Workhorse escribe la carga en un archivo temporal e inyecta ese parámetro por sí mismo. Un atacante simplemente lo envía directamente como un parámetro de cadena de consulta apuntando a cualquier lugar del sistema de archivos.

3. La coincidencia de rutas de Workhorse nunca decodifica el percent-encoding. Workhorse compara las rutas de carga contra EscapedPath(), los bytes de URL sin procesar tal como se reciben. Puma decodifica las secuencias %XX antes de enrutar a Grape. Por lo tanto, codificar un carácter en un segmento estático hace que Workhorse omita su regla de reescritura mientras Rails sigue enrutando al handler vulnerable:

4. Rack devuelve el contenido del archivo en la respuesta de error. Con Content-Type: application/x-www-form-urlencoded, el contenido del archivo se entrega a Rack::Utils.parse_nested_query. Cualquier % sin dos dígitos hexadecimales a continuación genera InvalidParameterError: invalid %-encoding (<content>). Todo hasta el primer & en el archivo se devuelve en el cuerpo del 400.

Los archivos sin % sin escape aún se leen antes de la autenticación. La respuesta 401 de la rama urlencoded y un 500 de la rama multipart confirman ambas que el archivo existe y es legible por el usuario git, lo que las hace útiles como oráculo de existencia.

Solicitud de exploit:

Características

• --file lee cualquier archivo individual; recurre automáticamente al oráculo si no hay un disparador de eco
• --loot ejecuta 36 objetivos en 7 niveles, ordenados por probabilidad confirmada de disparador de eco
• --oracle ejecuta una sonda de doble rama (urlencoded + multipart) contra archivos sin eco e indica si cada uno es legible, inexistente o ilegible
• --proc enumera /proc/self/fd/0-31 para encontrar descriptores de archivo abiertos, luego lee objetivos de reconocimiento estándar de /proc
• --shell entra en un shell interactivo de lectura de archivos con los comandos cat, loot, oracle, project y curl
• --pipe lee objetivos desde stdin y maneja salida de subfinder, texto de httpx, JSON de httpx, JSON de nuclei y líneas de host sin procesar
• --list toma un archivo de objetivos, uno por línea
• --threads para escaneo masivo concurrente
• --proxy enruta todo a través de Burp o mitmproxy
• --raw escribe bytes sin procesar en stdout sin decoración, útil para redirigir a un archivo
• --full ejecuta loot, oracle y proc en una sola pasada
• Salida de informe JSON y JSONL mediante -o
• Fingerprint de versión de GitLab con verificación de rango afectado
• Soporte de color en terminal de Windows

Instalación

Requiere Python 3.10 o superior. Sin otras dependencias.

Uso

Objetivo único

Pipeline

stdin se detecta automáticamente cuando no es un TTY, por lo que --pipe es opcional en la mayoría de los casos.

Shell

Veredictos de respuesta

Niveles de loot

Flags

Códigos de salida: 0 fuga confirmada, 1 solo oráculo o sin fugas en pipeline, 2 nada encontrado.

Parche

Corregido en el commit maestro 0d9ce3e7, retroportado como 1fe30154 / b43c8b26 / 0ff7b6b2.

Se cambiaron tres cosas al mismo tiempo:

1. authenticate! se movió antes de file_params_from_body_upload en los tres endpoints para que el archivo nunca se lea en una solicitud no autenticada
2. file.path ahora solo se acepta desde un objeto UploadedFile tipado producido por el middleware multipart, que requiere un JWT válido firmado por Workhorse, no desde un parámetro de cadena de consulta sin procesar
3. InvalidParameterError ya no interpola e.message en el cuerpo de la respuesta, por lo que el canal de eco se cierra incluso si alguien encontrara una forma de eludir las dos primeras correcciones

El bug se introdujo en GitLab 18.7 (diciembre de 2025) cuando se agregó la variante body-upload de la API de commits.

hecho con amor por @plur1bu5 -- si te resulta útil, se agradece una estrella