Una vulnerabilidad crítica de GitLab para leer archivos se explota en menos de un día tras hacerse pública la corrección

Los actores de amenazas comenzaron a sondear una vulnerabilidad crítica de GitLab apenas un día después de que la empresa anunciara las actualizaciones de seguridad, según investigadores que supervisan la actividad de explotación.

La vulnerabilidad, identificada como CVE-2026-85706, permite que un atacante no autenticado lea archivos arbitrarios de un servidor de GitLab autohospedado. La explotación requiere una única solicitud HTTP especialmente diseñada, por lo que las instalaciones expuestas y sin actualizar son objetivos prácticos para el análisis automatizado.

CVE-2026-85706 tiene una puntuación CVSS de 10 y ya figura en el catálogo de vulnerabilidades explotadas conocidas de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA). CISA la añadió el 11 de septiembre de 2026 y dio a las agencias federales hasta el 14 de septiembre de 2026 para corregir los sistemas afectados.

La versión de GitLab correspondiente también corrige otras 17 vulnerabilidades, entre ellas una segunda vulnerabilidad crítica y seis de gravedad alta. Por tanto, los administradores deben desplegar la actualización completa, en lugar de tratar el incidente como un problema de path traversal aislado.

El path traversal sin autenticación permite acceder a archivos del servidor

CVE-2026-85706 es una vulnerabilidad de path traversal en la API de commits de repositorios de GitLab. La restricción incorrecta de las rutas de archivo, combinada con la ausencia de controles de autenticación, permite que las solicitudes salgan de la ruta prevista y accedan a archivos ubicados en otras partes del servidor.

No se necesita una cuenta válida de GitLab. El ataque puede ejecutarse mediante una única solicitud HTTP.

Su vector CVSS es CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Esto refleja una vulnerabilidad explotable de forma remota, con baja complejidad de ataque, sin necesidad de privilegios ni interacción del usuario y con un impacto alto en la confidencialidad.

Según ese vector de puntuación, la vulnerabilidad no tiene un impacto directo en la disponibilidad. Sin embargo, el acceso a archivos arbitrarios puede revelar información que facilite ataques posteriores. Los archivos de un host de GitLab pueden contener la configuración de la aplicación, credenciales, tokens de acceso, código fuente, secretos de integraciones o datos sobre la infraestructura conectada.

Estas consecuencias dependen de los archivos accesibles y de la configuración de cada instalación. Los informes públicos no han identificado los archivos concretos recuperados durante los intentos de explotación observados ni han revelado compromisos posteriores confirmados atribuibles a dichos intentos.

WatchTowr observó intentos de explotación reales un día después de que GitLab anunciara sus parches y prevé una explotación más amplia. El breve intervalo deja muy poco margen entre la divulgación de la vulnerabilidad, la ingeniería inversa, el análisis y los intentos de compromiso.

Versiones exactas de GitLab CE y EE afectadas

La vulnerabilidad afecta a las instalaciones autohospedadas de GitLab Community Edition y Enterprise Edition comprendidas en estos rangos de versiones:

• GitLab CE y EE desde 18.7 hasta antes de 19.1.8
• GitLab CE y EE desde 19.2 hasta antes de 19.2.6
• GitLab CE y EE desde 19.3 hasta antes de 19.3.2

Los administradores deben actualizar a la versión corregida correspondiente a la rama instalada:

• 19.1.8 o posterior
• 19.2.6 o posterior
• 19.3.2 o posterior

Las organizaciones que utilicen ramas anteriores o mantenidas por separado deben obtener la versión corregida compatible y respaldada por el proveedor. No se han divulgado versiones afectadas específicas de los servicios en la nube ni instrucciones de mitigación.

Las instancias autohospedadas expuestas a Internet afrontan el riesgo más inmediato de ser analizadas, pero no debe ignorarse la exposición interna. Un atacante que ya tenga acceso a una red corporativa podría dirigirse a un servidor de GitLab accesible internamente mediante la misma solicitud sin autenticación.

Los sistemas de GitLab también ocupan una posición sensible en los entornos de desarrollo. Normalmente se conectan con runners, plataformas de despliegue, registros, proveedores de identidad, sistemas de gestión de tickets e infraestructuras en la nube. Por tanto, el acceso a los archivos del host podría revelar credenciales con un alcance que vaya más allá del propio GitLab.

Las búsquedas en los registros pueden revelar intentos de explotación

Los administradores de GitLab deben revisar los registros HTTP en busca de solicitudes POST enviadas a la API de commits de repositorios:

/api/v4/projects/{id}/repository/commits/

Las solicitudes que contengan un parámetro file.path deben investigarse, ya que podrían representar intentos de explotación contra CVE-2026-85706.

Este patrón, por sí solo, no debe considerarse automáticamente una prueba de compromiso. Los investigadores deben correlacionar las solicitudes coincidentes con las direcciones IP de origen, las marcas de tiempo, los códigos de respuesta, los accesos inusuales a archivos, la actividad de las cuentas y los cambios posteriores en repositorios o pipelines.

La investigación también debe examinar:

• Commits y modificaciones de repositorios realizados alrededor de la solicitud sospechosa
• Accesos a variables de CI/CD y secretos de proyectos
• Definiciones de pipelines y trabajos ejecutados recientemente
• Actividad de los runners y operaciones de compilación inesperadas
• Claves de despliegue, tokens de acceso personales o de proyectos e integraciones
• Cambios relacionados con usuarios, permisos, webhooks o ramas protegidas
• Artefactos de compilación generados o modificados recientemente
• Autenticaciones mediante credenciales almacenadas en el host de GitLab
• Actividad en entornos posteriores de despliegue y de paquetes

Las credenciales y los secretos que pudieran haberse expuesto deben rotarse. Los equipos deben validar las definiciones de los pipelines y volver a compilar los artefactos sensibles a partir de estados de origen confiables cuando no pueda descartarse un compromiso.

La aplicación del parche cierra la vulnerabilidad conocida, pero no elimina a un atacante que ya haya obtenido credenciales o modificado activos de desarrollo. Los sistemas que muestren solicitudes sospechosas requieren un análisis forense, además de la actualización.

CISA fija el 14 de septiembre como fecha límite para las agencias federales

CISA incorporó CVE-2026-85706 a su catálogo KEV el 11 de septiembre de 2026. La inclusión confirma que la explotación se está produciendo fuera de entornos de investigación controlados y transforma el problema de una exposición teórica en una prioridad operativa activa.

Las agencias civiles federales de Estados Unidos deben completar la corrección antes del 14 de septiembre de 2026.

CISA exige a las organizaciones afectadas aplicar las medidas de mitigación del proveedor y cumplir al mismo tiempo las directrices BOD 26-04 para priorizar las actualizaciones de seguridad en función del riesgo. Las agencias también deben seguir los requisitos de triaje forense de CISA.

En el caso de los servicios en la nube, las organizaciones deben seguir las directrices BOD 26-04 aplicables o dejar de utilizarlos cuando no existan medidas de mitigación eficaces. Cada responsable debe evaluar la exposición de sus activos a Internet y aplicar los requisitos de actualización correspondientes.

No se ha identificado ninguna solución alternativa que ofrezca una protección equivalente. Por tanto, instalar de inmediato la versión corregida de GitLab es la principal medida defensiva.

La actualización corrige otra vulnerabilidad crítica de GitLab

La misma actualización de seguridad corrige CVE-2026-87719, una vulnerabilidad de deserialización insegura en el serializador de suscripciones GraphQL de GitLab.

Tiene una puntuación CVSS de 9,9 y el vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. A diferencia de CVE-2026-85706, su explotación requiere privilegios de bajo nivel, pero sus posibles efectos abarcan la confidencialidad, la integridad y la disponibilidad.

Un atacante podría obtener acceso a las configuraciones de instancia de Advanced Search y a credenciales sensibles. Las versiones 19.1.8, 19.2.6 y 19.3.2 de GitLab CE y EE corrigen este problema.

La versión también corrige seis vulnerabilidades de gravedad alta capaces de permitir la ejecución remota de código, el acceso a variables protegidas de CI/CD, cross-site scripting o una denegación de servicio. No se dispone aquí de información sobre los demás defectos corregidos ni sobre todos sus rangos de versiones afectados.

Es importante desplegar la versión completa. Un sistema actualizado únicamente para corregir la vía de path traversal podría seguir expuesto a través de uno de los otros componentes corregidos.

La explotación rápida repite un caso anterior de GitLab

La actividad más reciente no es el único caso reciente de explotación casi inmediata al que se ha enfrentado GitLab. Anteriormente, los investigadores observaron ataques rápidos dirigidos contra CVE-2026-19478, una vulnerabilidad crítica de inyección de código en GraphQL.

CVE-2026-19478 tiene una puntuación CVSS de 9,4 y está clasificada como CWE-94. En determinadas condiciones, un atacante no autenticado podría aprovechar una directiva de GraphQL para modificar o eliminar de forma remota proyectos públicos y datos de usuarios.

Los rangos afectados eran:

• GitLab CE y EE desde 18.2 hasta antes de 18.11.11
• Desde 19.0 hasta antes de 19.0.8
• Desde 19.1 hasta antes de 19.1.6
• Desde 19.2 hasta antes de 19.2.4

La recurrencia demuestra la rapidez con la que los atacantes pueden convertir las vulnerabilidades de GitLab en operaciones, especialmente cuando pueden explotarse sin autenticación. Las plataformas de desarrollo concentran en un mismo lugar código valioso, secretos y controles de automatización.

Los administradores deben corregir CVE-2026-85706 de inmediato, conservar los registros pertinentes e investigar el tráfico sospechoso dirigido a la API de commits de repositorios. Cualquier indicio de acceso a archivos debe activar la rotación de credenciales y una revisión más amplia de pipelines, runners, integraciones, artefactos y despliegues posteriores.