GitLab publicó el lunes 12 de octubre una versión de emergencia para todas las instalaciones propias: 19.4.2, 19.3.5 y 19.2.8, con 24 correcciones de seguridad. La más grave, la CVE-2026-97229, tiene la nota máxima del sistema CVSS, un 10.0. Es un desbordamiento de entero en el compilador de expresiones regulares del CI/CD que, según el aviso, podía permitir a un usuario sin cuenta ni sesión iniciada ejecutar código en el servidor con una expresión regular manipulada en la configuración de CI/CD. GitLab.com ya tiene la corrección; quien tenga su propio servidor tiene que actualizar.
GitLab es una de las plataformas más usadas para alojar código y automatizar su compilación y despliegue, y muchas empresas la instalan en sus propios servidores para no sacar el código de casa. Esa versión instalada, llamada self-managed, es la que recibe estas correcciones. La compañía publica parches de seguridad programados el segundo y el cuarto miércoles de cada mes, y versiones extraordinarias cuando aparece un fallo grave: la de este lunes es de las segundas.
No es la primera de este otoño. El 10 de septiembre GitLab corrigió otro fallo con un CVSS de 10.0, la CVE-2026-85706, un recorrido de rutas en la API de commits que permitía leer archivos del servidor sin autenticarse. Ese fallo acabó en el catálogo de vulnerabilidades explotadas de la CISA, la agencia de ciberseguridad de Estados Unidos, y GitLab tuvo que llevar la corrección también a las versiones 19.0 y 18.11, ya fuera de su política de mantenimiento.
Claves de la actualización
- Qué falla. Según GitLab, es un desbordamiento de entero en el compilador de expresiones regulares del CI/CD, causado por una validación insuficiente de las expresiones que recibe, y podía acabar en la ejecución de código arbitrario. Las expresiones regulares aparecen en la configuración de CI/CD, por ejemplo en las condiciones
rules:ifcon=~, aunque GitLab no detalla por dónde entra la expresión del ataque. Lo descubrió el investigador joaxcar y lo comunicó por el programa de recompensas de HackerOne. - Por qué un 10.0. El vector CVSS lo explica pieza a pieza: se ataca por la red, con poca complejidad, sin privilegios y sin que nadie haga nada; el daño va más allá del componente vulnerable (alcance «cambiado») y el impacto es alto en confidencialidad, integridad y disponibilidad. No se puede puntuar peor.
- Versiones afectadas. Todas las de la 19.2 anteriores a la 19.2.8, las de la 19.3 anteriores a la 19.3.5 y las de la 19.4 anteriores a la 19.4.2, tanto Community Edition como Enterprise Edition. En la rama 19.3 hay que ir a la 19.3.5: la 19.3.4 tenía un error en las páginas de merge requests con la integración de Ona activada.
- Hay otras 23 correcciones. Cinco son de gravedad alta: un XSS en el resaltado de sintaxis (8.7), un fallo de autorización que dejaba a un desarrollador lanzar pipelines en ramas protegidas (8.5), un envenenamiento de caché de archivos del repositorio que podía exponer variables protegidas de CI/CD (8.2), otro de autorización en las políticas de ejecución de pipelines (7.7) y una inyección de instrucciones en el agente de IA de GitLab Duo (7.3). Las otras 18 son de gravedad media o baja.
- Una pista en las notas. Las tres versiones incluyen dos parches para el motor de expresiones regulares de Ruby 3.3 y 3.4, el lenguaje en que está escrita la mayor parte de GitLab: uno sobre el tamaño del programa compilado de una expresión regular y otro sobre una doble liberación de memoria en las repeticiones. GitLab no los relaciona con la CVE, y el detalle de cada fallo no se publicará hasta 90 días después.
- La actualización tiene coste. Incluye migraciones de base de datos: en una instalación de un solo servidor habrá una parada mientras terminan, y en las de varios nodos se puede aplicar sin cortar el servicio siguiendo el procedimiento de actualización sin parada. GitLab Dedicated no necesita hacer nada.
/help de tu instancia, o en el servidor con sudo gitlab-rake gitlab:env:info. Si está en la 19.2, la 19.3 o la 19.4 y no es una de las corregidas, actualiza ya, sin esperar a la ventana de mantenimiento. Si usas una versión más antigua, este fallo concreto no te afecta, pero otros del mismo aviso sí: lo recomendable es pasar a una versión con soporte.Por qué importa
Un servidor de GitLab guarda mucho más que código: las variables secretas de los pipelines, las claves para desplegar en producción, los tokens de acceso a la nube y los registros de contenedores. Quien ejecuta código en ese servidor tiene, en la práctica, las llaves de toda la cadena de entrega de software. Por eso un fallo que no exige ni siquiera una cuenta es de lo peor que le puede pasar a una instancia expuesta a internet.
El precedente de septiembre es el motivo para no esperar. GitLab no ha dicho que este fallo se esté aprovechando, pero el anterior de nota 10.0 acabó en la lista de vulnerabilidades explotadas de la CISA, y GitLab tuvo que publicar reglas para detectar los intentos de ataque. Dos fallos de gravedad máxima en poco más de un mes, uno de ellos en algo tan básico como validar una expresión regular, recuerdan que alojar tu propio GitLab también significa encargarte de parchearlo el mismo día.
Datos contrastados con el aviso de la versión 19.4.2 y con los avisos anteriores de GitLab: el de la 19.3.2 (10 de septiembre), donde se corrigió la CVE-2026-85706, y el de la 19.0.9 (23 de septiembre), que la llevó a las ramas antiguas. Portada: técnico trabajando en un rack del NERSC, foto de Derrick Coetzee, Wikimedia Commons, CC0 (recortada y teñida).
Fuente: GitLab, «GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8»