GitLab lanzó el 21 de octubre una actualización de seguridad que soluciona una vulnerabilidad crítica (CVE-2026-110264) en su compilador de expresiones regulares que, en ciertas condiciones, podría permitir a un atacante no autenticado ejecutar código arbitrario en servidores self‑managed.
Qué falla y por qué llega tan atrás
La raíz del problema está en Onigmo, el motor de expresiones regulares de Ruby que GitLab incluye y parchea dentro de sus paquetes. GitLab explica que un desbordamiento entero (integer overflow) durante la compilación de una expresión regular especialmente construida es lo que abre la posibilidad de ejecución remota. Como GitLab ha distribuido ese motor en sus builds desde la versión 7.0 (lanzada en 2014), la vulnerabilidad afecta a múltiples ramas y versiones históricas del producto.
Quiénes deben actuar y qué deben hacer
Solo las instalaciones self‑managed (autohospedadas) necesitan aplicar la actualización: GitLab.com ya ejecuta la versión corregida y los inquilinos de GitLab Dedicated en las ramas internas indicadas también la tienen. La compañía no ha publicado un workaround temporal; por tanto, la actualización es la única mitigación segura conocida según el aviso.
GitLab también advirtió que administradores que actualizaron el 12 de octubre pueden volver a estar en riesgo, porque aquella corrección cubría únicamente ramas a partir de la 19.2 y las versiones publicadas el 21 de octubre suben un parche por encima de esas ramas, reintroduciendo el rango afectado para algunas instancias actualizadas anteriormente.
Impacto técnico y operativa de la actualización
El parche del 21 de octubre corrige en total 11 problemas de seguridad (uno crítico y el resto de severidad alta, media o baja). Dos de las correcciones adicionales afectan a mecanismos de autenticación: una posibilidad de apropiación de cuenta para usuarios autenticados cuando SAML y el autoenlace LDAP están habilitados, y una falla de envenenamiento de caché en endpoints OAuth/OpenID Connect que podría redirigir flujos de inicio de sesión en configuraciones con caché compartida.
GitLab avisa que algunas de las versiones parcheadas (19.4.3 y 19.3.6 en su comunicado) incluyen cambios en la base de datos que se ejecutan durante la actualización; en servidores de nodo único esto implicará tiempo de inactividad mientras finalizan las migraciones. En despliegues multinodo pueden seguir el procedimiento de GitLab para aplicar la actualización sin tiempo de inactividad.
Detección y situación de explotación
Hasta la fecha señalada en el aviso de GitLab no había indicios públicos de explotación activa de esta vulnerabilidad, y no figuraba en el catálogo de vulnerabilidades explotadas de CISA al 22 de octubre. Para ayudar a la detección, GitLab publicó dos reglas de detección dentro de su marco TLDR en formato Sigma: «Onigmo native worker crash» y «Org mode render error burst», pensadas para buscar patrones de fallos en los registros de la aplicación que puedan indicar intentos de explotación.
Recomendaciones prácticas
- Administradores de instancias self‑managed: aplicar los parches publicados el 21 de octubre lo antes posible; no existe un mitigador temporal fiable.
- Planificar ventanas de mantenimiento si la instancia es de nodo único, dado que algunas actualizaciones ejecutan migraciones de base de datos.
- Revisar los logs con las reglas Sigma publicadas por GitLab para detectar intentos de explotación durante y después del parcheo.
- Si se requiere alta disponibilidad, seguir la guía de GitLab para actualizaciones sin downtime en entornos multinodo.
Nota: GitLab ha publicado la lista de versiones corregidas por rama; consulte el aviso oficial de seguridad de GitLab para identificar la versión de destino correspondiente a su instalación.
Lee también:
- Cloudflare WAF añade detección por transacción completa y reglas de respuesta
- Exploit público precede a parche crítico de PHP; proveedores y WordPress responden ajustando configuraciones
Fuente: The Hacker News
