GitLab publicó este lunes 12 de octubre de 2026 las versiones 19.4.2, 19.3.5 y 19.2.8 de GitLab Community Edition (CE) y Enterprise Edition (EE). La razón principal es CVE-2026-97229, una falla con la calificación máxima de 10.0 que, según el aviso del fabricante, "podría haber permitido a un usuario no autenticado ejecutar código arbitrario en el servidor de GitLab". El aviso pide que todas las instalaciones autoadministradas se actualicen de inmediato.
Es el segundo aviso crítico de GitLab en diez días. El 2 de octubre fue el turno del AI Gateway autohospedado con CVE-2026-90970, que solo tocaba a quien usaba la IA de Duo en servidores propios. Esta vez el problema está en el núcleo de GitLab, así que afecta a prácticamente cualquier servidor propio en esas ramas.
Qué se sabe
| Dato | Detalle |
|---|---|
| Vulnerabilidad | CVE-2026-97229 |
| Calificación | 10.0 (CVSS), crítica |
| Tipo | Desbordamiento de enteros en el compilador de expresiones regulares de CI/CD |
| Impacto | Ejecución de código en el servidor, sin autenticarse |
| Productos | GitLab CE y EE autoadministrados |
| Versiones corregidas | 19.4.2, 19.3.5 y 19.2.8 (12 oct 2026) |
| GitLab.com y Dedicated | Ya corregidos; no requieren acción |
| Explotación | Sin reportes al publicar; no estaba en el catálogo KEV de la CISA el 12 de octubre |
| Descubrimiento | Investigador joaxcar, vía el programa de recompensas de GitLab en HackerOne |
El paquete corrige 24 vulnerabilidades en total, cinco de ellas altas: entre otras, una que permite correr pipelines en ramas protegidas sin autorización (8.5), un envenenamiento de caché que puede exponer variables de CI/CD (8.2) y una inyección de instrucciones en Duo Agent Platform (7.3). Varias medias permiten leer contenido de proyectos privados sin iniciar sesión.
Qué versiones están afectadas
| Rama | Vulnerable | Instala |
|---|---|---|
| 19.4 | Anteriores a 19.4.2 | 19.4.2 |
| 19.3 | Anteriores a 19.3.5 | 19.3.5 |
| 19.2 | Anteriores a 19.2.8 | 19.2.8 |
Ojo: algunos reportes citan 19.3.4. GitLab la reemplazó por 19.3.5 porque traía un error en las páginas de merge requests; si ya la instalaste, sube a 19.3.5. Y si estás en una rama anterior a 19.2, no hay parche: toca migrar a una rama soportada.
¿Por qué actualizar hoy si nadie la explota todavía?
Por el historial reciente de GitLab. En septiembre, CVE-2026-85706 (también de 10, lectura de archivos sin autenticarse) entró al catálogo de vulnerabilidades explotadas de la CISA un día después de su parche, como contamos en el resumen de parches de septiembre. Según Cybersecurity Dive, los atacantes han usado al menos cinco vulnerabilidades de GitLab desde 2021.
Hay otra razón práctica: un servidor de GitLab no guarda solo código. Ahí viven las variables de CI/CD con contraseñas de bases de datos, llaves de la nube, tokens de despliegue y credenciales del PAC o del ERP que usan los pipelines. Quien ejecuta código en ese servidor tiene, de paso, acceso a todo lo que el servidor puede tocar.
A quién le afecta en México
- Casas de software y equipos de desarrollo que tienen GitLab en un servidor propio, una VM en la nube o un VPS.
- Empresas con desarrollo interno (integraciones con el ERP, timbrado, portales de clientes, apps) que montaron GitLab hace años y lo dejaron "funcionando".
- Proveedores de software a la medida: tu código y tus credenciales pueden estar en su GitLab.
- Quien usa GitLab.com en la nube está cubierto, pero debe revisar sus Runners propios por separado: se actualizan aparte del servidor.
Qué hacer hoy
Si administras tu propio GitLab
- Revisa la versión. En la interfaz, en Admin → Overview → Dashboard (o en
/help), o en el servidor consudo gitlab-rake gitlab:env:info. - Respalda antes de actualizar. Corre
sudo gitlab-backup createy copia aparte/etc/gitlab/gitlab-secrets.jsonygitlab.rb; sin ese archivo de secretos el respaldo sirve de poco. Si no tienes una política de respaldos clara, la plantilla de política de respaldos es un buen punto de partida. - Planea una ventana corta para hoy. El parche incluye migraciones de base de datos: en una instalación de un solo nodo habrá una interrupción mientras terminan.
- Actualiza a 19.4.2, 19.3.5 o 19.2.8 según tu rama. Si estás varias versiones atrás, sigue la ruta de actualización oficial de GitLab; saltar versiones mayores rompe instalaciones.
- Si no puedes actualizar hoy, reduce la exposición. Deja GitLab accesible solo por VPN o por direcciones IP conocidas, y desactiva el registro abierto de usuarios.
- Revisa señales raras de los últimos días: usuarios o tokens nuevos que nadie pidió, pipelines que se ejecutaron fuera de horario, cambios en variables de CI/CD y procesos desconocidos en el servidor.
- Rota los secretos más sensibles si el servidor estuvo expuesto a internet sin parche: llaves de nube, credenciales de producción y tokens de despliegue.
Si un proveedor administra tu código
Pregúntale hoy por escrito: ¿usan GitLab propio para nuestros proyectos? ¿Ya está en 19.4.2, 19.3.5 o 19.2.8? ¿Dónde guardan nuestras credenciales de producción? Pide versión y fecha, no un "ya quedó".
La lección de fondo
Dos avisos críticos en diez días no son motivo para abandonar GitLab, sino para que actualizarlo sea rutina: respaldo, ventana conocida, actualización y prueba de un pipeline. Si tus pipelines dependen de pasos manuales, la guía práctica de CI/CD con GitLab ayuda a ordenarlos.
Si quieres que revisemos tu servidor de GitLab, tus Runners y dónde están guardadas tus credenciales, nuestro equipo de desarrollo de software y de ciberseguridad puede hacerlo contigo.
Fuentes: aviso GitLab Critical Patch Release 19.4.2, 19.3.5, 19.2.8 (12 de octubre de 2026); Cybersecurity Dive (12 de octubre de 2026).
