GitLab ha publicado actualizaciones de seguridad para sus ediciones Community Edition (CE) y Enterprise Edition (EE) con el fin de corregir múltiples vulnerabilidades. Entre ellas destacan dos fallos de severidad crítica que permiten la lectura arbitraria de archivos sin autenticación y el robo de credenciales y configuraciones sensibles. Adicionalmente, se solventó una vulnerabilidad de severidad alta en GitLab EE que posibilita la ejecución remota de código (RCE) mediante la importación de proyectos maliciosos.
Las versiones con los parches correspondientes (19.3.2, 19.2.6 y 19.1.8) fueron liberadas el 10 de septiembre de 2026.
CVE y severidad
| ID | Severidad (CVSS) | Impacto | Componente afectado | Vector / Requisitos de explotación |
|---|---|---|---|---|
| CVE-2026-85706 | Crítica (10.0) | Lectura arbitraria de archivos | API de commits del repositorio | Remoto / Sin autenticación (bajo condiciones específicas) |
| CVE-2026-87719 | Crítica (9.9) | Fuga de credenciales y configuraciones | Serializador de suscripciones GraphQL (EE) | Remoto / Requiere usuario autenticado con acceso a Duo Chat |
| CVE-2026-88765 | Alta (8.5) | Ejecución remota de código (RCE) | Conversor Unicode durante indexación de búsqueda avanzada (EE) | Remoto / Requiere usuario autenticado e importación de proyecto manipulado |
Nota: La actualización también corrige vulnerabilidades adicionales de severidad alta que comprometen variables de entorno de CI/CD protegidas, renderizado de Markdown y manejo de recursos GraphQL.
Productos afectados
| Producto | Edición | Versiones afectadas |
|---|---|---|
| GitLab | Community Edition (CE) |
18.7 hasta 19.1.7 |
| GitLab | Enterprise Edition (EE) |
18.3 hasta 19.1.7 |
Solución
Actualizar de manera urgente a las versiones oficiales remediadas de acuerdo a la rama soportada en su infraestructura:
- GitLab v19.3.2
- GitLab v19.2.6
- GitLab v19.1.8
Recomendaciones
GitLab recomienda a todos los clientes con instalaciones autogestionadas aplicar las actualizaciones de inmediato. Las implementaciones de nodo único experimentarán tiempo de inactividad durante las migraciones de base de datos, mientras que los entornos multinodo pueden utilizar el proceso de actualización sin tiempo de inactividad si están configurados correctamente.