GitLab corrige una falla de severidad máxima y la explotan un día después

CVE-2026-85706 tiene puntuación CVSS de 10.0 y permite a un atacante sin autenticación leer archivos arbitrarios del servidor. WatchTowr detectó los primeros intentos a las 24 horas.

GitLab publicó la corrección de la CVE-2026-85706, un recorrido de rutas con la puntuación máxima posible en la escala CVSS: 10.0. Un día después aparecieron los primeros intentos de explotación.

La falla

La vulnerabilidad permite a un atacante sin autenticación leer archivos arbitrarios del servidor GitLab. Sin credenciales, sin interacción del usuario, sin condiciones previas.

El alcance cubre Community Edition y Enterprise Edition 18.7 anteriores a 19.1.8, la rama 19.2 anterior a 19.2.6 y la 19.3 anterior a 19.3.2.

Las versiones corregidas son 19.1.8, 19.2.6 y 19.3.2.

La velocidad de la explotación

La firma WatchTowr detectó sondeos activos en internet un día después de la publicación del parche, el viernes. La firma anticipa que la explotación masiva llegará poco después.

El patrón se repite con cada falla de lectura arbitraria en software autogestionado de alto valor: la publicación del parche es también la publicación del mapa que lleva a la vulnerabilidad, y quien ingenia el exploit a partir de la corrección gana la carrera contra quien programa la ventana de mantenimiento.

Por qué un servidor GitLab es un objetivo de primer orden

La lectura arbitraria de archivos suena menos grave que la ejecución de código. En un servidor GitLab, la diferencia se difumina.

Ese servidor guarda el código fuente completo de la organización, los archivos de configuración con cadenas de conexión a bases de datos, las variables de entorno de los pipelines, los tokens de despliegue hacia los proveedores de nube y, con frecuencia, llaves privadas de firma.

Leer esos archivos entrega al atacante las credenciales para moverse a producción sin volver a tocar GitLab.

Qué significa para los equipos de desarrollo dominicanos

La acción es inmediata: verificar la versión desplegada y actualizar. La ventana razonable se mide en horas.

El punto ciego habitual está en las instancias autogestionadas que un equipo levantó hace años y que funcionan sin supervisión. Muchas fintech, casas de software y áreas internas de TI en el país operan GitLab sobre un servidor propio o una instancia de nube, con el ciclo de actualización a criterio del desarrollador que lo instaló.

Para las organizaciones que ya corrieron el parche, queda una segunda tarea: asumir posible lectura previa y rotar los secretos que vivían en ese servidor —tokens de despliegue, claves de API, credenciales de base de datos—, porque el parche cierra la puerta sin revocar lo que ya salió por ella.

Fuentes