GitLab corrige un fallo crítico 10 sobre 10: qué versión poner

GitLab publicó el 12 de octubre de 2026 las versiones 19.4.2, 19.3.5 y 19.2.8 para corregir un fallo crítico, puntuado con 10 sobre 10, que en ciertas condiciones dejaba ejecutar código en el servidor sin iniciar sesión. Afecta a los GitLab instalados en servidor propio desde la 19.2. GitLab.com ya está corregido.

Lo que se sabe

  • Qué publicó GitLab: según su nota de parche del 12 de octubre, las versiones 19.4.2, 19.3.5 y 19.2.8, para las ediciones Community y Enterprise, corrigen 24 fallos de seguridad: 1 crítico, 5 altos, 14 medios y 4 bajos.
  • El fallo grave: la misma nota describe el CVE-2026-97229 como un desbordamiento de enteros en el compilador de expresiones regulares de CI/CD, la parte que lee las reglas de los pipelines. GitLab dice que, en ciertas condiciones, un usuario sin autenticar podía ejecutar código en el servidor. Le da 10,0 en la escala CVSS.
  • Versiones afectadas: según GitLab, todas desde la 19.2 anteriores a la 19.2.8, la 19.3 anteriores a la 19.3.5 y la 19.4 anteriores a la 19.4.2.
  • Quién lo encontró: un investigador con el alias «joaxcar», a través del programa de recompensas de GitLab en HackerOne.
  • Quién no tiene que hacer nada: GitLab dice que GitLab.com ya funciona con la versión corregida y que los clientes de GitLab Dedicated no tienen que actuar.
  • La 19.3.4: la nota explica que esa versión tenía un error en las páginas de merge requests con la integración Ona activada, corregido en la 19.3.5.
  • Caída durante la actualización: el parche incluye migraciones de base de datos. En instalaciones de un solo nodo GitLab avisa de que habrá caída, porque las migraciones deben terminar antes de que arranque. En instalaciones de varios nodos se puede hacer sin caída.
  • Ataques: ninguna de las fuentes consultadas habla de ataques en curso con este fallo. BleepingComputer y The Hacker News lo contaron el 12 y el 13 de octubre.

Qué cambia y qué no

Si tu equipo guarda el código de la web en GitLab.com, no tienes que hacer nada por este fallo.

Cambia para quien tiene su propio GitLab en un servidor o un VPS, algo habitual para guardar el código de una web y desplegarla con pipelines. Ahí la actualización no es automática: alguien tiene que hacerla.

El resto de fallos del parche son menores, pero hay varios de permisos y uno de inyección de instrucciones en la plataforma de agentes de IA de GitLab Duo (solo en la edición Enterprise, 7,3 sobre 10). Todos se corrigen con las mismas versiones.

Si tu GitLab es anterior a la 19.2, el aviso no lo incluye entre las afectadas por el fallo crítico, pero tampoco publica correcciones para esas ramas.

Cómo saber si te afecta

  1. Mira dónde está tu GitLab. Si entras por gitlab.com, ya está. Si entras por una dirección propia (por ejemplo, git.tuempresa.com), sigue con los pasos.
  2. Mira la versión. Con una cuenta de administrador, la versión aparece en el área de administración y en la página de ayuda de tu instancia (la dirección /help).
  3. Elige la versión de destino según tu rama: 19.4.x → 19.4.2; 19.3.x → 19.3.5, también si ya instalaste la 19.3.4; 19.2.x → 19.2.8.
  4. Planifica la caída. Si tu GitLab está en un solo servidor, avisa al equipo: durante la actualización no habrá pushes ni despliegues. Haz antes una copia de seguridad.
  5. Revisa los despliegues de la web. Si tu GitLab estuvo abierto a internet con una versión afectada, mira quién puede crear o cambiar pipelines y valora cambiar las claves que la web usa para desplegar (acceso al hosting, FTP, API) guardadas como variables de CI/CD.
  6. Si el servidor lo lleva otra persona o un proveedor, pregúntale: «¿Qué versión de GitLab tenemos y cuándo pasamos a la 19.4.2, la 19.3.5 o la 19.2.8?».

Relacionado: GhostAction vuelve: workflows falsos roban claves en GitHub

Fuentes

Actualizaciones: aquí se añadirá si GitLab u otra fuente primaria informa de ataques que usen este fallo.