GitLab corrige una lectura de ficheros sin autenticar con CVSS 10 y ya hay escaneos
La vulnerabilidad afecta a la API de commits de instancias autoalojadas de GitLab CE y EE y permite leer ficheros del servidor sin autenticarse. Las versiones 19.1.8, 19.2.6 y 19.3.2 lo corrigen.
GitLab ha publicado parches para una vulnerabilidad en la API de commits de sus instancias autoalojadas que permite leer ficheros del servidor sin autenticarse. La compañía la puntúa con un 10,0 de CVSS, el máximo de la escala, y según watchTowr ya se han visto sondeos contra instancias expuestas a internet el día siguiente a hacerse pública. No hay confirmación pública de que nadie haya llegado a leer nada.
Qué hace falta para explotarla
El atacante no necesita cuenta ni interacción de ningún usuario. Basta con alcanzar por red la API de commits de una instancia vulnerable y mandar una petición POST sin autenticar con el parámetro file.path apuntando fuera del alcance previsto. Si se cumplen las condiciones del producto, el servidor devuelve el contenido de archivos que no debería entregar. No hay ejecución de código: es una lectura, y quien la consiga se lleva lo que hubiera dentro. Si ahí aparecen tokens de configuración o credenciales en logs, el paso siguiente es usarlos para hacerse pasar por un usuario o un servicio legítimo.
De momento eso es inferencia, no hecho comprobado. Lo que sí está documentado es la fase de reconocimiento: watchTowr reportó peticiones de sondeo en entornos reales. Nadie ha publicado que se haya completado una lectura, ni una autenticación exitosa con credenciales robadas, ni movimiento posterior hacia runners, repositorios, variables de CI/CD o servicios en la nube integrados.
Las versiones corregidas son la 19.1.8, la 19.2.6 y la 19.3.2, cada una para su rama. Afecta a GitLab CE y EE autoalojados. Junto al CVE-2026-85706, el aviso viene acompañado del CVE-2026-87719, del que no se ha dado detalle público.
Cómo se detecta
El ataque no pinta nada en la interfaz: no hay pantalla ni interacción de usuario, así que quien use GitLab con normalidad no va a notar nada. La pista está en los logs: peticiones POST sin autenticar a la API de commits con file.path conteniendo secuencias de salto de directorio. Cuidado con esto, porque si el proxy solo registra la URL no verás nada: file.path viaja en el cuerpo de la petición y hace falta que el registro capture el body.
Si la instancia estuvo expuesta sin parchear, toca revisar si el proceso de GitLab leyó archivos de configuración o logs fuera de lo habitual. Si esos registros no existen, no hay forma de saber a posteriori si alguien leyó algo. El propio aviso contempla también correlacionar el registro de auditoría con el historial de operaciones en los entornos cloud conectados, aunque ahí depende de qué esté activado.
Lo primero es actualizar. Y después, si la instancia ha estado expuesta, rotar los secretos: tokens, credenciales de servicios integrados y variables de CI/CD. Restringir el acceso a la API por VPN o listas de permitidos reduce la superficie, y limitar permisos y ubicación de los ficheros sensibles acota el daño de una lectura exitosa, pero ninguna de las dos cosas sustituye al parche ni a la rotación.
