GitLab, otro fallo 10 sobre 10: toca actualizar de nuevo

GitLab publicó el 21 de octubre de 2026 un parche crítico para otro fallo puntuado con 10 sobre 10 que, en ciertas condiciones, deja ejecutar código en el servidor sin iniciar sesión. Afecta a los GitLab instalados en servidor propio desde la versión 7.0, también a los que se actualizaron el 12 de octubre. GitLab.com ya está corregido.

Lo que se sabe

  • Qué publicó GitLab: según su nota de parche del 21 de octubre, las versiones 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13 de las ediciones Community y Enterprise. Corrigen 12 fallos de seguridad: 1 crítico, 2 altos, 5 medios y 4 bajos.
  • El fallo grave: la nota describe el CVE-2026-110264 como un desbordamiento de enteros al compilar una expresión regular preparada a propósito. 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 7.0 anteriores a la 18.11.13, y en las ramas nuevas la 19.0 antes de la 19.0.10, la 19.1 antes de la 19.1.9, la 19.2 antes de la 19.2.9, la 19.3 antes de la 19.3.6, la 19.4 antes de la 19.4.3 y la 19.5 antes de la 19.5.1.
  • No es el fallo del 12 de octubre: aquel era el CVE-2026-97229 y se corregía con la 19.4.2, la 19.3.5 y la 19.2.8. Esas tres versiones siguen dentro del rango afectado por el nuevo.
  • Dónde está el fallo: según The Hacker News, en Onigmo, el motor de expresiones regulares de Ruby que GitLab incluye en sus paquetes. El mismo medio dice que no hay solución temporal: solo actualizar.
  • Quién lo encontró: el mismo investigador que el del día 12, «joaxcar», a través del programa de recompensas de GitLab en HackerOne.
  • Quién no tiene que hacer nada: GitLab.com ya funciona con la versión corregida. En GitLab Dedicated, los clientes con la 19.3.5-internal0, la 19.4.2-internal0 o posteriores ya tienen el arreglo.
  • Caída durante la actualización: el parche trae migraciones de base de datos. En instalaciones de un solo nodo habrá caída, porque las migraciones deben terminar antes de que GitLab arranque. En varios nodos se puede hacer sin caída.
  • Ataques: la nota de GitLab no habla de ataques en curso. The Hacker News dice que el fallo no estaba en el catálogo de fallos explotados de CISA. GitLab publicó dos reglas de detección para quien tenga su propio servidor.

Qué cambia y qué no

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

Cambia para quien tiene su propio GitLab en un servidor o un VPS. Haber actualizado el 12 de octubre no basta: la versión que se instaló ese día tiene el fallo nuevo.

También cambia para quien se quedó en una versión anterior a la 19.2. El parche del 12 no las incluía; este sí, y la versión más antigua que recibe el arreglo es la 18.11.13. Quien esté por debajo de la rama 18.11 tiene que subir al menos a esa versión.

El resto de fallos del parche son de permisos, autenticación, caché y exposición de credenciales internas. Se corrigen con las mismas versiones.

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.
  2. Mira la versión. Con una cuenta de administrador aparece en el área de administración y en la página /help de tu instancia.
  3. Elige la versión de destino según tu rama: 19.5.x → 19.5.1; 19.4.x (también la 19.4.2 del día 12) → 19.4.3; 19.3.x (también la 19.3.5) → 19.3.6; 19.2.x (también la 19.2.8) → 19.2.9; 19.1.x → 19.1.9; 19.0.x → 19.0.10; 18.11 o anterior → 18.11.13 como mínimo.
  4. Planifica la caída. En un solo servidor, durante la actualización no habrá pushes ni despliegues de la web. Haz antes una copia de seguridad.
  5. Revisa los despliegues. Si tu GitLab estuvo abierto a internet con una versión afectada, valora cambiar las claves que la web usa para desplegar (acceso al hosting, FTP, API) guardadas en las 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 versión del parche del 21 de octubre para nuestra rama?».

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

Fuentes

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