CVE-2026-85706 en GitLab: parchee ya las instancias autogestionadas expuestas

CVE-2026-85706 es una vulnerabilidad de severidad máxima en GitLab Community Edition (CE) y Enterprise Edition (EE) autogestionados. Tiene una puntuación CVSS 3.1 de 10,0 y, bajo determinadas condiciones, permite que un atacante sin autenticación lea archivos arbitrarios del servidor de GitLab. No es un riesgo meramente teórico: CISA la incluyó como vulnerabilidad conocida por estar siendo explotada y los investigadores ya han detectado sondeos contra instancias expuestas a internet. 32122

La prioridad: actualizar de inmediato

Si su instalación autogestionada usa una versión vulnerable, debe actualizar cuanto antes a una de estas versiones corregidas:

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

Están afectadas las versiones de GitLab CE/EE desde la 18.7 hasta antes de la 19.1.8, 19.2 hasta antes de la 19.2.6 y 19.3 hasta antes de la 19.3.2. GitLab publicó las correcciones el 10 de septiembre de 2026. 37

CISA —la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU.— añadió CVE-2026-85706 a su catálogo Known Exploited Vulnerabilities (KEV) el 11 de septiembre, con fecha límite de actuación del 14 de septiembre para las agencias civiles federales estadounidenses incluidas en ese requisito. El plazo no obliga automáticamente a las empresas privadas, pero refleja la urgencia para cualquier despliegue autogestionado accesible desde internet. 3

Qué permite hacer la vulnerabilidad

El fallo se localiza en la API de Repository Commits de GitLab. Su causa documentada combina un confinamiento incorrecto de rutas controladas por el usuario con la falta de aplicación de autenticación. En esas condiciones, una petición no autenticada puede leer archivos a los que tenga acceso el servicio de GitLab. 3

Se trata principalmente de una vulnerabilidad de divulgación de archivos. La información disponible no demuestra que CVE-2026-85706, por sí sola, permita ejecutar código remoto. Sin embargo, leer archivos arbitrarios puede exponer elementos útiles para un compromiso posterior: configuración de la aplicación, tokens, claves SSH, credenciales de bases de datos u otros secretos legibles por el proceso de GitLab. 925

Por qué la explotación activa cambia la respuesta

WatchTowr informó de sondeos detectados en el mundo real, incluso a través de su red de honeypots el 11 de septiembre. La presencia en KEV es otra señal relevante: el catálogo de CISA identifica vulnerabilidades para las que existe evidencia de explotación. 222

Los informes públicos confirman actividad de sondeo y explotación, pero no identifican a un único actor responsable, ni aportan un número fiable de víctimas, ni prueban una cadena de poscompromiso universal. La ausencia de un incidente conocido no debe interpretarse como prueba de que un servidor expuesto no fue consultado.

Trate los servidores expuestos como posibles incidentes de exposición de secretos

Instalar el parche detiene el comportamiento vulnerable, pero no revierte datos que ya podrían haberse leído. En servidores afectados y accesibles desde internet, conserve evidencias y evalúe primero a qué podía acceder la cuenta de servicio de GitLab.

Dé prioridad a revisar y rotar:

• Secretos de configuración y de aplicación de GitLab.
• Credenciales de base de datos, Redis, almacenamiento de objetos, registro de contenedores, SMTP, servicios de directorio e identidad que estén en la configuración.
• Variables de CI/CD, deploy tokens, access tokens, tokens de runners, claves de despliegue y credenciales usadas por trabajos o integraciones.
• Claves de nube, credenciales de registros de paquetes, claves de firma y claves privadas SSH o TLS accesibles desde el host o el proceso de GitLab.

Planifique la rotación con cuidado. Cambiar secretos de aplicación o ajustes ligados al cifrado puede invalidar sesiones e interrumpir configuraciones o integraciones cifradas. Antes de una limpieza amplia, guarde logs y configuraciones relevantes, defina la recuperación y rote primero las credenciales de mayor riesgo.

Detección: qué buscar en los registros

Un indicador inicial útil es una solicitud HTTP POST a esta ruta de la API Repository Commits:

/api/v4/projects/<id>/repository/commits/

Los reportes recomiendan buscar solicitudes que contengan el parámetro file.path. Revise los logs del proxy inverso, balanceador, WAF y acceso de GitLab Rails en busca de peticiones no autenticadas inusuales, entradas codificadas con aspecto de traversal, identificadores de proyecto inesperados, errores repetidos, patrones de enumeración o tamaños de respuesta anómalos. 212426

Investigue también actividad posterior a la ventana de posible exposición: creación o uso de tokens, registro de runners, cambios en variables de CI/CD o definiciones de pipelines, importaciones inusuales, actividad GraphQL y conexiones salientes inesperadas. Las guías publicadas tras el lanzamiento también recomiendan revisar commits, suscripciones GraphQL, importaciones de proyectos y pipelines de CI/CD. 23

Una búsqueda sin resultados no es concluyente: la retención puede ser limitada, los registros de la aplicación quizá no capten todos los detalles y los del proxy o WAF podrían ser la única evidencia disponible.

Controles temporales si no puede actualizar de inmediato

La actualización es la corrección necesaria. Si no puede realizarla de emergencia, reduzca la exposición restringiendo el acceso al servicio web y API de GitLab a una VPN o a redes autorizadas. Una regla en proxy inverso o WAF que limite estrictamente la ruta afectada puede reducir el riesgo a corto plazo, pero puede romper automatizaciones legítimas y no sustituye al parche.

La secuencia práctica para cada servidor afectado es:

1. Identificar y priorizar las instancias autogestionadas accesibles desde el exterior.
2. Actualizar a 19.1.8, 19.2.6, 19.3.2 o una versión más reciente.
3. Comprobar la versión en ejecución después del cambio.
4. Conservar y revisar los logs en busca de indicadores de explotación.
5. Rotar secretos potencialmente expuestos según el acceso del servidor y el impacto para el negocio.

Otros fallos corregidos en el lanzamiento

Los mismos reportes de seguridad describieron dos problemas adicionales de Enterprise Edition corregidos en el lanzamiento:

• CVE-2026-87719 se reporta como un problema de deserialización insegura autenticada, con CVSS 9,9, asociado en algunos informes a la exposición de configuración y credenciales de Advanced Search. 6
• CVE-2026-88765 se reporta como un riesgo de ejecución remota de código autenticada mediante la importación de una exportación de proyecto Git manipulada, con CVSS 8,5. 625

Sus requisitos y efectos son distintos de los de CVE-2026-85706. Para instalaciones autogestionadas expuestas, la vulnerabilidad no autenticada de lectura de archivos bajo explotación activa debe seguir siendo la primera prioridad de contención y respuesta.