GitLab CVE-2026-85706: un 10 sobre 10 que deja leer archivos sin autenticarse
GitLab parcheó el 10 de septiembre CVE-2026-85706, un recorrido de rutas con CVSS 10.0 que deja leer archivos del servidor sin autenticarse. En menos de 24 horas ya había sondeos en internet y CISA lo sumó a su catálogo de vulnerabilidades explotadas.
La mayoría de las brechas empiezan en una dependencia olvidada o un token mal guardado. Esta vez el agujero estaba en la herramienta que guarda el código.
Qué es el fallo CVE-2026-85706
CVE-2026-85706 es una vulnerabilidad de recorrido de rutas (path traversal) en la API de commits del repositorio de GitLab. Combina dos errores: un confinamiento de rutas incorrecto y la falta de aplicación de la autenticación. Bajo ciertas condiciones, alguien sin cuenta ni token puede pedir un archivo del servidor y GitLab se lo entrega.
Recorrido de rutas en la API de commits
El recorrido de rutas es un clásico: el atacante construye una ruta que sube por el sistema de archivos y el programa no valida el destino final. Aquí el vector es la API de commits, y el detalle que complica la detección es que la ruta viaja en el cuerpo de la petición, no en la URL.
Lee también
Sin usuario y sin contraseña: por qué es un 10 sobre 10
La escala CVSS castiga la combinación de explotación remota, sin autenticación, sin interacción del usuario y pérdida total de confidencialidad. CVE-2026-85706 reúne las cuatro condiciones, y por eso la puntuación es el máximo posible. No hace falta una técnica avanzada: basta con alcanzar el servicio.
Qué se puede leer: configuración, logs, tokens y claves
En esa máquina viven el archivo de configuración, los logs de la aplicación y del proxy inverso, los datos de conexión a la base de datos y, muy a menudo, claves SSH y tokens de integración. Con esas credenciales se entra a otros sistemas sin volver a tocar la vulnerabilidad original.
Qué versiones están afectadas
El aviso es para instancias autoalojadas, tanto Community Edition como Enterprise Edition. Si usas GitLab.com o GitLab Dedicated no tienes nada que hacer: el parche se aplicó en el servidor.
GitLab CE y EE: de la rama 18.7 a la 19.3.1
Son vulnerables las versiones anteriores a la 19.1.8 dentro de la rama 19.1, las anteriores a la 19.2.6 en la 19.2 y las anteriores a la 19.3.2 en la 19.3. Las ramas más antiguas, desde la 18.7 hacia atrás, también quedan en el rango afectado y ya no reciben mantenimiento: ahí toca saltar a una versión soportada.
Las versiones parcheadas: 19.3.2, 19.2.6 y 19.1.8
GitLab publicó las versiones corregidas el 10 de septiembre de 2026 para ambas ediciones, en un lanzamiento con más de una decena de correcciones de seguridad y errores. Se instalan por los canales habituales, ya sea el paquete del sistema o la imagen del contenedor.
GitLab.com y GitLab Dedicated ya están cubiertos
La compañía confirmó que sus servicios en la nube quedaron parcheados al momento de la divulgación. El riesgo real está en las instalaciones que cada equipo administra en su VPS o en su servidor de oficina.
Los ataques llegaron en menos de 24 horas
Del parche del 10 de septiembre a los sondeos del 11
La firma de seguridad watchTowr reportó actividad de sondeo el 11 de septiembre, un día después de la divulgación, y advirtió que la explotación masiva era probable por lo sencillo del vector. Hoy la ventana entre "ya hay parche" y "ya hay escaneos" se mide en horas, no en semanas.
CISA añade el fallo al catálogo KEV con plazo el 14 de septiembre
La agencia de ciberseguridad de Estados Unidos lo incluyó en su catálogo de vulnerabilidades explotadas el 11 de septiembre, con fecha límite de remediación para agencias federales civiles el 14. Entrar en esa lista significa explotación real, no teórica.
El segundo fallo del mismo parche: CVE-2026-87719
El lanzamiento traía además CVE-2026-87719, una deserialización insegura en el serializador de suscripciones GraphQL, con CVSS 9.9 y limitada a Enterprise Edition. No conviene confundir los dos fallos: el primero es lectura de archivos sin autenticación y afecta a CE y EE.
Qué hacer si administras una instancia autoalojada
Actualizar primero, preguntar después
La mitigación recomendada es actualizar a 19.3.2, 19.2.6 o 19.1.8 según tu rama. Una VPN o una lista de IP permitidas reduce la superficie mientras preparas la ventana de mantenimiento, pero no sustituye al parche.
Revisar los logs: peticiones a la API de commits con secuencias de recorrido
Como la ruta viaja en el cuerpo de la petición, la URL del log no basta para detectar el intento: hay que buscar peticiones no autenticadas a la API de commits y revisar sus parámetros. La comunidad ya publicó guías forenses y escáneres de indicadores de compromiso para este CVE.
Rotar secretos y claves si la instancia estuvo expuesta
Si tu servidor estuvo accesible desde internet y sin parche durante esos días, asume que los archivos de configuración pudieron leerse: rota tokens de acceso, claves SSH y credenciales de base de datos. Es trabajo, pero sale mucho más barato que una intrusión.
Conclusión
La lección es la misma del ataque a RubyGems que ya contamos en el blog: las herramientas de desarrollo son objetivo prioritario porque concentran credenciales y acceso a todo lo demás. Parchear GitLab hoy es una tarea de minutos; investigar un incidente después es una tarea de semanas.
Si quieres seguir con el tema, el blog tiene el ataque con agentes de IA a RubyGems, seguridad en código abierto y las mejores prácticas de seguridad en Laravel.
