Una vulnerabilidad de path traversal en GitLab entra en CISA KEV con un plazo de tres días para aplicar el parche

GitLab insta a los administradores de instalaciones autogestionadas a aplicar un parche para una vulnerabilidad de máxima gravedad que puede exponer archivos arbitrarios a través de la API de commits de repositorios.

Identificada como CVE-2026-85706, la vulnerabilidad de path traversal afecta tanto a GitLab Community Edition como a Enterprise Edition. En determinadas condiciones, un atacante no autenticado puede explotarla de forma remota mediante una única solicitud HTTP.

CISA añadió la vulnerabilidad a su catálogo de vulnerabilidades explotadas conocidas el 11 de septiembre de 2026. Las agencias federales estadounidenses deben completar la corrección antes del 14 de septiembre de 2026, lo que deja un plazo inusualmente reducido de tres días.

GitLab afirmó no haber confirmado ninguna explotación en entornos reales. Sin embargo, la empresa de seguridad watchTowr observó sondeos a escala global de Internet en busca de servidores de GitLab sin parchear. La inclusión en KEV también implica que los equipos de defensa deben tratar el problema como una amenaza activa, no como una debilidad teórica.

El acceso no autenticado a la API puede exponer archivos del servidor

CVE-2026-85706 se debe a un confinamiento inadecuado de las rutas y a la falta de controles de autenticación en la funcionalidad de commits de repositorios expuesta a través de la API de GitLab. La vulnerabilidad está clasificada como CWE-22, es decir, una restricción incorrecta de un nombre de ruta a un directorio limitado.

Un atacante puede manipular el tratamiento de las rutas de archivo en el endpoint de commits de repositorios para que el servidor de GitLab acceda a contenido situado fuera del directorio previsto. No se necesita una cuenta válida ni la interacción de un usuario, y el ataque descrito puede llevarse a cabo mediante una sola solicitud.

Una explotación satisfactoria puede revelar cualquier archivo que el servicio de GitLab pueda leer según la configuración específica del servidor. Entre los posibles objetivos se incluyen:

• Archivos de configuración de aplicaciones e infraestructura
• Credenciales y tokens de acceso
• Claves de API y otros secretos
• Código fuente propietario
• Datos de repositorios
• Archivos que contienen información sobre servicios conectados

La información técnica disponible confirma la lectura arbitraria de archivos. No demuestra que CVE-2026-85706 permita por sí sola ejecutar código de forma remota ni modificar directamente archivos del servidor.

La vulnerabilidad tiene una puntuación CVSS 3.1 de 10,0 y el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Esta calificación describe un ataque accesible a través de la red, de baja complejidad y que no requiere privilegios ni la intervención del usuario. El vector registrado asigna un impacto alto sobre la confidencialidad y la integridad, sin impacto sobre la disponibilidad.

El investigador “s3ntago” notificó la vulnerabilidad a través del programa de recompensas por errores de GitLab en HackerOne.

Versiones afectadas exactas y objetivos de actualización seguros

La vulnerabilidad afecta a GitLab CE y EE en tres rangos de versiones:

• Versiones desde 18.7 hasta antes de la 19.1.8
• Versiones desde 19.2 hasta antes de la 19.2.6
• Versiones desde 19.3 hasta antes de la 19.3.2

Por tanto, los operadores deben actualizar a 19.1.8, 19.2.6 o 19.3.2, según la rama de lanzamiento implementada.

Algunos informes describieron la corrección de forma más general como aplicable a la rama 19.1. Los administradores deben utilizar 19.1.8 como límite de corrección pertinente, en lugar de asumir que cualquier versión 19.1 es segura.

La exposición inmediata afecta a las instalaciones autogestionadas, especialmente a los servidores accesibles desde Internet público. GitLab.com ya utilizaba una versión parcheada, mientras que se informó a los clientes de GitLab Dedicated de que no necesitaban tomar ninguna medida.

Aun así, las organizaciones deben verificar su modelo de implementación y no confiar únicamente en la marca GitLab asociada a un servicio interno. Las instancias alojadas internamente y mantenidas por unidades de negocio, equipos de desarrollo, filiales o proveedores externos pueden quedar fuera de los procesos centralizados de aplicación de parches.

La inclusión en CISA eleva la prioridad de respuesta

CISA incorporó CVE-2026-85706 al catálogo KEV el 11 de septiembre de 2026, con una fecha límite federal de corrección del 14 de septiembre de 2026.

La respuesta exigida indica a las agencias que deben aplicar las medidas de mitigación del proveedor, cumplir la BOD 26-04, «Priorizar las actualizaciones de seguridad en función del riesgo», y respetar los requisitos de triaje forense de CISA. Las agencias que utilicen servicios en la nube deben seguir las disposiciones aplicables de la BOD 26-04 o dejar de utilizarlos cuando no haya medidas de mitigación eficaces. Los responsables de los activos también deben evaluar la exposición a Internet y cumplir los requisitos de aplicación de parches basados en el riesgo establecidos por la directiva.

Existe una diferencia entre las declaraciones públicas sobre la explotación. GitLab no había identificado ningún incidente confirmado, mientras que watchTowr informó de escaneos y sondeos, no de ataques exitosos verificados. Al mismo tiempo, la inclusión en KEV indica que CISA considera que la vulnerabilidad cumple sus criterios de explotación conocida.

No se ha identificado públicamente ningún actor de amenazas, campaña, organización víctima, dirección IP maliciosa, payload, agente de usuario ni ruta de archivo objetivo. La ausencia de estos datos dificulta la atribución, pero no debe retrasar la corrección.

El reconocimiento a escala global de Internet suele preceder a la explotación una vez que se comprenden el endpoint y la estructura de las solicitudes de una vulnerabilidad. En este caso, la ausencia de autenticación y la posibilidad de realizar el ataque mediante una sola solicitud reducen el coste operativo para los atacantes.

Qué deben buscar los equipos de defensa

Los administradores deben revisar los registros de la aplicación GitLab y todos los registros del proxy inverso, balanceador de carga, firewall de aplicaciones web o API gateway situados delante del servicio.

El patrón más relevante es una solicitud HTTP POST dirigida a un URI con una estructura similar a esta:

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

Las solicitudes que contengan un parámetro file.path requieren una investigación adicional. Esta combinación puede indicar actividad de explotación, aunque la información disponible no ofrece detalles suficientes para considerar concluyentemente maliciosa cada solicitud coincidente.

No se han divulgado cadenas de payload ni secuencias de traversal específicas. Los equipos de defensa deben conservar todos los datos de las solicitudes cuando sea posible desde el punto de vista legal y operativo, incluidos los registros de tiempo, las direcciones de origen, las cabeceras, los parámetros, los códigos de respuesta y los tamaños de las respuestas.

Si se detectan solicitudes sospechosas, los equipos de respuesta a incidentes deben determinar qué archivos podía leer la cuenta de servicio de GitLab. La investigación debe abarcar directorios de configuración, almacenamiento de repositorios, archivos de entorno, ajustes de integraciones, copias de seguridad, credenciales, tokens y secretos utilizados para acceder a sistemas externos.

Cuando existan indicios de acceso arbitrario a archivos, los secretos afectados deben considerarse expuestos y sustituirse. Los equipos también deben revisar los servicios posteriores a los que se pueda acceder con esas credenciales. La aplicación del parche cierra la vulnerabilidad, pero no invalida el material que un atacante ya haya obtenido.

Un segundo fallo crítico afecta a GitLab Enterprise Edition

Las mismas actualizaciones de seguridad corrigen CVE-2026-87719, una vulnerabilidad independiente de deserialización insegura en GitLab Enterprise Edition.

Este fallo requiere un usuario autenticado con acceso a Duo Chat. En determinadas condiciones, el usuario puede proporcionar un argumento de suscripción GraphQL manipulado que elude el tratamiento de serialización previsto y activa la búsqueda de objetos del servidor.

El acceso resultante puede exponer configuraciones de instancias de Advanced Search y credenciales confidenciales. A diferencia de CVE-2026-85706, esta vulnerabilidad requiere privilegios de bajo nivel y no permite un ataque anónimo.

CVE-2026-87719 tiene una puntuación CVSS 3.1 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. Está clasificada como CWE-502, deserialización de datos no confiables.

Los rangos afectados de Enterprise Edition son:

• Versiones desde 18.3 hasta antes de la 19.1.8
• Versiones desde 19.2 hasta antes de la 19.2.6
• Versiones desde 19.3 hasta antes de la 19.3.2

CVE-2026-87719 no figura en el catálogo KEV de CISA. No obstante, las organizaciones que utilicen Duo Chat y Advanced Search deben incluirla en su revisión, especialmente al investigar actividad autenticada sospechosa.

GitLab ha sufrido repetidos fallos del lado del servidor incluidos en KEV

La nueva entrada en KEV se suma a otras vulnerabilidades de GitLab que permitieron a los atacantes acceder a datos o recursos internos mediante funciones del lado del servidor.

CVE-2023-2825 fue otra vulnerabilidad de path traversal con una puntuación CVSS de 10,0, limitada a GitLab CE/EE 16.0.0. Permitía la lectura de archivos sin autenticación cuando había un archivo adjunto en un proyecto público anidado dentro de al menos cinco grupos.

Otros dos fallos antiguos de falsificación de solicitudes del lado del servidor también entraron en el catálogo KEV en 2026. CVE-2021-39935, que afectaba a la API de CI Lint, se añadió el 3 de febrero de 2026, con una fecha límite federal del 24 de febrero de 2026. CVE-2021-22175, relacionada con solicitudes de webhook a redes internas, se incorporó el 18 de febrero de 2026, con una fecha límite de corrección del 11 de marzo de 2026.

En el caso de CVE-2026-85706, la respuesta es clara: identificar todas las instancias autogestionadas, actualizar a la versión corregida de su rama, examinar el tráfico de la API e investigar posibles accesos a datos. Los sistemas expuestos a Internet deben tener prioridad.