NoticiasNews

GitLab CVE-2026-85706: falla CVSS 10 explotada activamente y CISA fija el 14 de septiembre como fecha límiteGitLab CVE-2026-85706: CVSS 10 Flaw Under Active Exploitation, CISA Sets September 14 Deadline

2026-09-14

El 10 de septiembre de 2026 GitLab publicó un parche crítico para Community Edition (CE) y Enterprise Edition (EE) que corrige CVE-2026-85706, una vulnerabilidad de path traversal (CWE-22) en la API de commits de repositorios con puntuación CVSSv3.1 de 10.0, la máxima posible. Según GitLab, una combinación de confinamiento de rutas defectuoso y ausencia de verificación de autenticación permite que un usuario no autenticado lea archivos arbitrarios de un servidor GitLab afectado bajo ciertas condiciones.

Un día después, el 11 de septiembre, la Agencia de Ciberseguridad y Seguridad de Infraestructura de Estados Unidos (CISA) incorporó la falla a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV) con base en evidencia de explotación activa, y fijó el 14 de septiembre de 2026 como fecha límite de remediación para las agencias federales civiles. CISA además marcó la vulnerabilidad como sujeta a requisitos de triaje forense bajo la Directiva Operativa Vinculante 26-04. La firma watchTowr reportó que los atacantes ya estaban rastreando internet en busca de servidores GitLab sin parchear.

Qué versiones están afectadas

Todos los tipos de despliegue autogestionado están afectados: Omnibus, instalación desde código fuente y chart de Helm. Las versiones corregidas son:

  • Versiones desde 18.7 hasta antes de 19.1.8, corregidas en 19.1.8.
  • Versiones desde 19.2 hasta antes de 19.2.6, corregidas en 19.2.6.
  • Versiones desde 19.3 hasta antes de 19.3.2, corregidas en 19.3.2.

GitLab.com ya corre una versión parcheada y los clientes de GitLab Dedicated no necesitan tomar acción. Las actualizaciones incluyen migraciones de base de datos: las instalaciones de un solo nodo experimentarán tiempo de inactividad mientras corren, mientras que los despliegues multinodo pueden usar el procedimiento de actualización sin downtime. De las versiones corregidas, solo 19.3.2 incluye migraciones posteriores al despliegue.

No es la única falla del parche

La misma publicación corrige otras 17 vulnerabilidades. Entre ellas destaca CVE-2026-87719, una deserialización insegura (CWE-502) en GitLab EE con CVSSv3.1 de 9.9: bajo ciertas condiciones, un usuario autenticado con acceso a Duo Chat podría obtener configuraciones de Advanced Search y credenciales sensibles mediante un argumento de suscripción GraphQL manipulado. Al momento de la publicación, solo CVE-2026-85706 se conocía como explotada en el mundo real.

Por qué importa más allá del área de desarrollo

Un servidor GitLab autogestionado rara vez contiene solo código. Típicamente almacena variables de entorno, archivos de configuración, tokens de integración, credenciales de despliegue y llaves de acceso a servicios de terceros. Una lectura arbitraria de archivos sin autenticación convierte esa concentración de secretos en un punto único de compromiso que puede escalar hacia producción, sistemas internos y cadenas de suministro de software.

Por eso Rapid7 recomienda explícitamente buscar señales de compromiso incluso después de haber aplicado la actualización: si el servidor estuvo expuesto a internet antes del parche, la posibilidad de que ya se hayan extraído secretos debe tratarse como un escenario probable, no hipotético. La respuesta correcta combina tres pasos: parchear de emergencia fuera del ciclo normal, rotar todo secreto que haya vivido en el servidor y revisar registros de acceso a la API de commits.

La lección operativa

El patrón se repite con frecuencia incómoda: divulgación, parche, prueba de concepto pública y explotación masiva en cuestión de días. Entre el parche de GitLab (10 de septiembre) y la fecha límite de CISA (14 de septiembre) pasaron apenas cuatro días. Las organizaciones que no tienen un inventario actualizado de qué corren, en qué versión y expuesto a qué red, simplemente no pueden responder a esa velocidad.

En TEKFENIX construimos software empresarial a medida y productos SaaS bajo la premisa de que la gestión de vulnerabilidades no es un evento aislado sino un proceso con trazabilidad. Con Servigo365, nuestra mesa de ayuda multicanal con IA, los avisos críticos como este se convierten en tickets priorizados con responsable, SLA y evidencia de cierre, en lugar de correos que se pierden entre canales. Y con CumplimientoControl ese mismo rastro de acciones y aprobaciones queda disponible para auditoría regulatoria. Si su organización opera instancias autogestionadas de GitLab u otras herramientas críticas, conversemos sobre cómo darle estructura y trazabilidad a su respuesta ante incidentes.

On September 10, 2026, GitLab published a critical patch release for Community Edition (CE) and Enterprise Edition (EE) fixing CVE-2026-85706, a path traversal vulnerability (CWE-22) in the repository commits API carrying a CVSSv3.1 score of 10.0, the maximum possible. According to GitLab, improper path confinement combined with missing authentication enforcement allows an unauthenticated user to read arbitrary files from an affected GitLab server under certain conditions.

One day later, on September 11, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalog based on evidence of active exploitation, setting September 14, 2026 as the remediation due date for Federal Civilian Executive Branch agencies. CISA also marked the vulnerability as subject to forensic triage requirements under Binding Operational Directive 26-04. Security firm watchTowr reported attackers were already probing the internet for unpatched GitLab servers.

Affected versions

All self-managed deployment types are affected: Omnibus, source install and Helm chart. The fixed versions are:

  • All versions from 18.7 before 19.1.8, fixed in 19.1.8.
  • All versions from 19.2 before 19.2.6, fixed in 19.2.6.
  • All versions from 19.3 before 19.3.2, fixed in 19.3.2.

GitLab.com already runs a patched version and GitLab Dedicated customers need take no action. The updates include database migrations: single-node installations will experience downtime while they run, whereas multi-node deployments can use the zero-downtime upgrade procedure. Of the fixed releases, only 19.3.2 includes post-deployment migrations.

Not the only flaw in the release

The same patch release addresses 17 other vulnerabilities. Among them is CVE-2026-87719, a critical insecure deserialization issue (CWE-502) in GitLab EE with a CVSSv3.1 score of 9.9: under certain conditions, an authenticated user with Duo Chat access could obtain Advanced Search instance configurations and sensitive credentials using a specially crafted GraphQL subscription argument. At time of publication, only CVE-2026-85706 was known to be exploited in the wild.

Why this matters beyond the dev team

A self-managed GitLab server rarely holds only code. It typically stores environment variables, configuration files, integration tokens, deployment credentials and third-party access keys. Unauthenticated arbitrary file read turns that concentration of secrets into a single point of compromise that can escalate into production, internal systems and software supply chains.

That is why Rapid7 explicitly recommends looking for signs of compromise even after applying the update: if the server was internet-facing before the patch, the possibility that secrets were already exfiltrated should be treated as likely, not hypothetical. The correct response combines three steps: emergency patching outside the normal cycle, rotating every secret that lived on the server, and reviewing access logs for the commits API.

The operational lesson

The pattern repeats with uncomfortable frequency: disclosure, patch, public proof of concept and mass exploitation within days. Between GitLab’s patch (September 10) and CISA’s deadline (September 14), only four days passed. Organizations without an up-to-date inventory of what they run, at which version and exposed to which network, simply cannot respond at that speed.

At TEKFENIX we build custom enterprise software and vertical SaaS products on the premise that vulnerability management is not an isolated event but a traceable process. With Servigo365, our AI-powered multichannel help desk, critical advisories like this one become prioritized tickets with an owner, an SLA and closure evidence, instead of emails lost across channels. And with CumplimientoControl, that same trail of actions and approvals stays available for regulatory audit. If your organization runs self-managed GitLab or other critical tooling, let’s talk about giving structure and traceability to your incident response.

← Volver al blog← Back to blog