CVE-2026-85706: Grave fallo de recorrido de ruta en GitLab explotado en la naturaleza

GitLab ha lanzado actualizaciones de seguridad de emergencia para una vulnerabilidad de máxima gravedad en las ediciones Community Edition (CE) y Enterprise Edition (EE) que permite a atacantes no autenticados leer archivos arbitrarios de servidores vulnerables. Identificada como CVE-2026-85706 y evaluada con un 10.0 en la escala CVSS, la falla reside en la API de commits del repositorio y es resultado de una confinación de ruta inadecuada combinada con la falta de aplicación de autenticación.

El riesgo escaló casi inmediatamente después de la divulgación. Los investigadores de seguridad observaron un sondeo a nivel mundial en internet comenzando aproximadamente a las 06:00 UTC del 11 de septiembre de 2026, poco después de que GitLab lanzara parches. Posteriormente, CISA añadió la vulnerabilidad a su catálogo de Vulnerabilidades Explotadas Conocidas basado en evidencia de explotación activa.

La explotación exitosa puede exponer archivos sensibles almacenados en el servidor de GitLab, incluyendo datos de configuración, credenciales, secretos, registros y otra información accesible al servicio de GitLab. En entornos de desarrollo, esos archivos pueden contener secretos de CI/CD, credenciales de despliegue, tokens, datos relacionados con el código fuente, e información que podría facilitar comprometer el sistema.

La falla es particularmente peligrosa para instalaciones autogestionadas de GitLab expuestas a internet porque no requiere una cuenta, privilegios existentes, o interacción del usuario. Según watchTowr, el requisito principal para la ruta de ataque observada es que la instancia de GitLab contenga al menos un proyecto público.

Análisis de CVE-2026-85706

La vulnerabilidad es un problema de recorrido de ruta en la API de commits del repositorio de GitLab. GitLab describe la causa raíz como confinamiento insuficiente de rutas de archivos combinado con la falta de aplicación de autenticación en la funcionalidad afectada. Esto permite que la información de ruta controlada por el atacante escape de la ubicación donde GitLab espera que residan los archivos del repositorio y haga referencia a otros archivos disponibles para la aplicación.

El vector CVSS asignado por GitLab es CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Refleja una vulnerabilidad explotable de forma remota con baja complejidad de ataque, sin requisito de autenticación, y sin interacción del usuario. GitLab asigna impactos altos a la confidencialidad e integridad, mientras que la disponibilidad no se ve directamente afectada por la primitiva de lectura de archivos.

Los detalles más importantes para CVE-2026-85706 son que los atacantes pueden interactuar con la API de commits del repositorio vulnerable de forma remota y solicitar rutas que deberían estar fuera del directorio permitido del repositorio. Si GitLab falla al contener correctamente esa ruta, el servidor puede devolver el contenido de un archivo arbitrario accesible al proceso de GitLab.

Según watchTowr, la explotación puede exponer archivos de configuración y registros específicos de GitLab que contengan credenciales, secretos y otra información sensible. Dependiendo de la configuración del sistema y los permisos de archivos, los atacantes también pueden apuntar a claves SSH, archivos de entorno, credenciales de bases de datos, tokens de despliegue u otros datos sensibles de la aplicación.

CVE-2026-85706 afecta las siguientes versiones de GitLab CE y EE:

• Todas las versiones de 18.7 antes de 19.1.8
• Todas las versiones de 19.2 antes de 19.2.6
• Todas las versiones de 19.3 antes de 19.3.2

GitLab.com ya estaba ejecutando la versión parcheada cuando se divulgó el problema, mientras que los clientes de GitLab Dedicated no necesitan tomar medidas. El requisito de remediación urgente se aplica principalmente a las organizaciones que operan instancias autogestionadas de GitLab.

El requisito de al menos un proyecto público incrementa significativamente la exposición de organizaciones que intencionadamente hospeda repositorios de código abierto, proyectos de desarrollo públicos, recursos comunitarios u otro contenido accesible anónimamente en su propia infraestructura de GitLab. Un atacante no necesita ser miembro del proyecto o tener una cuenta válida de GitLab antes de intentar la explotación.

Las consecuencias pueden extenderse más allá de la simple divulgación de información. GitLab frecuentemente se encuentra en el centro de canalizaciones de desarrollo de software y almacena material altamente sensible, incluyendo código fuente, variables de CI/CD, credenciales de despliegue, configuración de infraestructura, tokens de acceso, y secretos de integración.

Si un atacante obtiene tales credenciales a través del acceso arbitrario a archivos, la vulnerabilidad inicial de GitLab puede convertirse en un trampolín para actividades adicionales de intrusión. Los secretos robados podrían potencialmente proporcionar acceso a repositorios de código fuente, infraestructura de CI/CD, servicios en la nube, registros de contenedores, sistemas de despliegue, u otros recursos conectados.

Esto también introduce un riesgo en la cadena de suministro de software. El acceso a credenciales de desarrollo o infraestructura de construcción podría permitir a un atacante intentar cambios no autorizados en el repositorio, manipular procesos de construcción, robar código propietario, o comprometer sistemas aguas abajo que confían en los artefactos producidos a través del entorno de GitLab afectado.

GitLab reconoció al investigador de seguridad s3ntago por reportar la vulnerabilidad a través del programa de recompensas de errores HackerOne de la compañía. La fecha exacta de descubrimiento privado y reporte no ha sido divulgada públicamente. GitLab lanzó versiones corregidas el 10 de septiembre de 2026 y documentó públicamente la falla como parte de su lanzamiento crítico de parches.

La transición de la divulgación a la actividad hostil fue extremadamente rápida. WatchTowr dijo que su red de honeypots Attacker Eye detectó sondas de comportamiento que apuntaban a la vulnerabilidad aproximadamente desde las 06:00 UTC del 11 de septiembre, indicando que actores externos ya habían invertido ingeniería inversa en la debilidad y comenzado a probar sistemas de GitLab accesibles por internet.

CISA añadió la falla a su catálogo de KEV más tarde el 11 de septiembre después de confirmar evidencia de explotación activa. Se instruyó a las agencias de la Rama Ejecutiva Civil Federal a remediar los sistemas afectados antes del 14 de septiembre de 2026, y CISA también marcó la vulnerabilidad como requiriendo un examen forense bajo la Directiva Operacional Vinculante 26-04.

El código PoC público de CVE-2026-85706 también apareció pronto después de la divulgación, reduciendo aún más la barrera técnica para los atacantes interesados en reproducir el comportamiento de lectura arbitraria de archivos. Combinado con la baja complejidad de la vulnerabilidad y la ruta de ataque no autenticada, la reproducción pública aumenta la probabilidad de una explotación oportuna más amplia.

Actualmente no hay un conjunto integral de IOCs específicos de campaña para CVE-2026-85706 tales como direcciones IP de atacantes, dominios, o hashes de malware que puedan identificar de manera confiable la explotación. En su lugar, el indicador más útil es la estructura de las solicitudes que apuntan a la API vulnerable de GitLab.

WatchTowr recomienda buscar solicitudes HTTP POST dirigidas a rutas que coincidan con:

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

Los defensores deben prestar especial atención cuando esas solicitudes contengan parámetros de ruta de archivo sospechosos o parezcan solicitar archivos no relacionados con el repositorio al que se accede.

Mitigación de CVE-2026-85706

GitLab recomienda encarecidamente que todas las instalaciones autogestionadas afectadas se actualicen inmediatamente a una de las versiones corregidas:

• GitLab 19.1.8
• GitLab 19.2.6
• GitLab 19.3.2

Cualquier versión posterior soportada que contenga la corrección de seguridad también debería abordar la vulnerabilidad. Los administradores deben verificar la versión exacta que están ejecutando en lugar de asumir que se ha realizado la actualización automática.

Las organizaciones que no puedan aplicar el parche inmediatamente deberían eliminar el acceso público innecesario a la instancia de GitLab afectada o restringir la conectividad en el proxy inverso, firewall, balanceador de carga, o capa de red hasta que pueda completarse la actualización. Esta es solo una medida temporal de reducción de exposición y no debe reemplazar la instalación de la versión corregida de GitLab.

La detección de CVE-2026-85706 debe comenzar con identificar todas las instancias autogestionadas de GitLab, sus versiones exactas, y si eran accesibles desde internet después del 10 de septiembre. Los sistemas que hospedan uno o más proyectos públicos deben recibir una prioridad de investigación particularmente alta.

Para detectar la explotación o el reconocimiento de CVE-2026-85706, los defensores deben revisar la telemetría de GitLab, del proxy inverso, WAF, y del servidor web para:

• Solicitudes HTTP POST a /api/v4/projects/{id}/repository/commits/
• Solicitudes que contengan parámetros de ruta de archivo inusuales
• Secuencias de recorrido de ruta que intentan salir de los directorios de repositorio esperados
• Solicitudes de archivos de configuración o registro de GitLab a través de APIs de repositorios
• Gran número de solicitudes de la API de commits del repositorio desde fuentes previamente no vistas
• Acceso anónimo seguido de intentos inusuales de recuperar recursos del lado del servidor
• Acceso inesperado a credenciales, archivos de configuración, o secretos de aplicación
• Nueva actividad de autenticación usando credenciales que pueden haber sido expuestas a través de GitLab
• Acceso inexplicado a infraestructura de CI/CD, nube, registro, o despliegue después de actividad sospechosa en GitLab

WatchTowr recomienda específicamente revisar el patrón de la API de commits del repositorio porque puede proporcionar evidencia directa de intentos de sondeo o explotación contra el punto final vulnerable.

El parcheo también deberá ser combinado con una investigación retrospectiva. El requisito de CISA para un examen forense refleja la posibilidad de que las organizaciones hayan sido comprometidas antes de desplegar la corrección, particularmente dado lo rápidamente que comenzaron los ataques después de la divulgación.

Si se identifica actividad de lectura de archivo sospechosa, los administradores deben determinar exactamente qué archivos pudieron haber sido accedidos. Los secretos contenidos en archivos potencialmente expuestos deben considerarse comprometidos hasta que se demuestre lo contrario.

Las organizaciones deben considerar rotar:

• Tokens de acceso de GitLab y tokens de acceso personal
• Tokens de despliegue
• Variables y secretos de CI/CD
• Credenciales de bases de datos
• Claves SSH
• Credenciales de la nube
• Credenciales de registro de contenedores
• Tokens de API e integración
• Secretos de OAuth
• Credenciales de despliegue y automatización

Los equipos de seguridad también deben investigar sistemas aguas abajo que confiaban en esas credenciales. Actualizar GitLab cierra la ruta de lectura de archivos vulnerable pero no puede invalidar secretos ya obtenidos por un atacante.

Para sistemas de alto riesgo, los defensores deben comparar la actividad reciente del repositorio, pipeline, cuenta, corredor, y despliegue con registros conocidos para identificar posibles abusos posteriores. Modificaciones inesperadas de pipeline, cambios en repositorios, tokens emitidos recientemente, o acceso inusual a infraestructura de construcción deben investigarse.

Dada la severidad CVSS 10.0, la explotación confirmada, la reproducción pública, y la rápida transición de la divulgación a la exploración, la remediación debe tratarse como una emergencia para los despliegues autogestionados de GitLab que están expuestos a internet.