GitLab publica parche crítico para CVE-2026-110264 en instalaciones self-managed

El 21 de octubre GitLab publicó parches críticos para una vulnerabilidad que permite la ejecución remota de código en servidores autogestionados sin necesidad de autenticación. La falla, registrada como CVE-2026-110264 y calificada con 10.0 en la escala CVSS, afecta a todas las versiones de GitLab desde la 7.0 (2014) hasta ramas recientes, porque el error reside en el motor de expresiones regulares Onigmo embalado dentro de los paquetes de GitLab. GitLab afirma que no hay indicios públicos de explotación hasta la fecha y que las instancias alojadas en gitlab.com ya ejecutan la versión corregida; sin embargo, la naturaleza y el alcance temporal del parche requieren atención inmediata por parte de los administradores de instalaciones self‑managed.

Técnicamente, la vulnerabilidad es un desbordamiento entero (integer overflow) que se desencadena durante la compilación de una expresión regular especialmente construida. En términos prácticos, cuando el compilador de expresiones regulares (Onigmo, la derivación de Oniguruma integrada en Ruby) procesa una entrada maliciosa puede calcular mal tamaños o índices internos, provocando condiciones que permiten sobrescribir memoria crítica y, en última instancia, ejecutar instrucciones arbitrarias con los privilegios del proceso de GitLab. El vector preciso —qué rutas de la aplicación aceptan esa expresión regular y qué precondiciones deben cumplirse para que llegue al compilador— no ha sido descrito por GitLab en detalle; por tanto, no hay forma de excluir administrativamente una instalación sin aplicar el parche.

Confirmado por GitLab está lo siguiente: la compañía lanzó correcciones el 21 de octubre y ya había publicado un parche parcial el 12 de octubre que cubría únicamente las ramas 19.2 en adelante. Eso significa que una instancia que se actualizó el 12 de octubre puede volver a quedar vulnerable si la nueva corrección retrocede el parche a versiones anteriores o incrementa el rango de versiones afectadas. GitLab también ha backporteado la solución a varias ramas antiguas (por ejemplo, 18.11.13, 19.0.10, 19.1.9 y 19.2.9), una medida que la compañía suele reservar para problemas de severidad extrema.

La raíz del problema —Onigmo incrustado en los paquetes— explica por qué la falla alcanza versiones tan antiguas: GitLab no depende únicamente de la implementación de Ruby presente en el sistema operativo, sino que distribuye un paquete propio de Onigmo dentro de su build, con sus propias correcciones y versiones. El código vulnerable por tanto viaja dentro de cada paquete oficial de GitLab que incluya esa copia de Onigmo.

Además del parche principal, el paquete del 21 de octubre corrige otras vulnerabilidades incluidas en la misma publicación. Entre ellas hay problemas de autenticación y un fallo de cache‑poisoning en endpoints OAuth/OIDC. GitLab advierte que ciertas actualizaciones (específicamente las versiones 19.4.3 y 19.3.6) ejecutan migraciones de base de datos durante la actualización; en servidores de nodo único esto implica tiempo de inactividad mientras la migración se completa, mientras que las arquitecturas multinodo pueden aplicar el procedimiento de “zero‑downtime” documentado por GitLab.

Sobre la explotación activa: GitLab reporta no haber detectado ataques vinculados a CVE-2026-110264 y, al 22 de octubre, la vulnerabilidad no figuraba en el catálogo de vulnerabilidades explotadas del gobierno de EE. UU. (CISA). Sin embargo, esa constatación no garantiza que no exista actividad dirigida ni que un atacante no la descubra en el futuro, sobre todo por la severidad máxima y porque el mismo investigador ha identificado varias vulnerabilidades en el compilador de regex recientemente.

GitLab publicó también reglas de detección para ayudar a los administradores a identificar intentos de aprovechamiento a partir de logs de aplicación: las firmas se denominan “Onigmo native worker crash” y “Org mode render error burst” y forman parte del proyecto TLDR de detección de GitLab, con reglas en formato Sigma. Es útil emplearlas como parte de una respuesta rápida, pero GitLab mismo indica que la única protección segura es aplicar el parche, ya que no ha detallado las precondiciones necesarias para que la expresión regular maliciosa alcance el compilador.

Qué deberían hacer ahora los administradores (hechos confirmados y pasos prácticos): primero, identificar si su instancia es self‑managed y consultar la lista de versiones corregidas publicada por GitLab; si lo es, planificar la actualización a la versión que contiene la corrección publicada el 21 de octubre. Revise la página oficial de seguridad y el repositorio TLDR para obtener las versiones exactas y las reglas de detección: GitLab Security y GitLab TLDR (reglas Sigma). Haga una copia de seguridad completa de datos y del estado de la base de datos antes de aplicar la actualización y, si su instalación es de nodo único, programe la ventana de mantenimiento necesaria para la migración. Para despliegues multinodo, siga el procedimiento de actualización sin tiempo de inactividad recomendado por GitLab.

Recomendaciones adicionales basadas en prácticas de respuesta a incidentes y la información disponible: monitorice logs aplicando las reglas TLDR y active alertas por picos de errores relacionados con workers nativos o fallos de renderización org mode; considere rotar credenciales sensibles y revisar logs de acceso y proceso para cualquier comportamiento anómalo inmediatamente previo o posterior a la actualización; y, si detecta indicadores de compromiso, aísle la instancia afectada y proceda con un análisis forense. En ausencia de un parche inmediato posible, minimice la exposición de la interfaz de GitLab a Internet (VPN, listas de control de acceso), aunque esto no garantiza protección si la vía de entrada es una funcionalidad interna que quede accesible por usuarios autenticados o por hooks internos.

Hay incertidumbres importantes que conviene destacar: GitLab no ha publicado qué rutas o APIs pueden desencadenar la compilación vulnerable ni qué recursos o permisos necesita un atacante para enviar la expresión regular maliciosa. Por tanto, no puede descartarse por configuración que una instalación concreta esté a salvo hasta que se aplique la corrección. Tampoco hay evidencia pública de explotación, pero la simplicidad relativa de un exploit contra un desbordamiento en un componente comúnmente expuesto convierte esta situación en un riesgo alto por probabilidad y severidad combinadas.

Finalmente, conviene situar esto en contexto: este es el cuarto fallo en el motor de expresiones regulares reportado por el mismo investigador en pocas semanas, y el primero que alcanza versiones tan antiguas de GitLab. Para reducir la ventana de riesgo en el futuro, las organizaciones deberían revisar procesos de gestión de parches que permitan aplicar correcciones críticas con máxima rapidez, automatizar las verificaciones de versión y contar con procedimientos pre‑definidos para aplicar migraciones de base de datos en entornos productivos minimizando interrupciones. Para referencias y recursos oficiales sobre la incidencia y detección consulte la página de seguridad de GitLab y el catálogo de CISA sobre vulnerabilidades conocidas: https://about.gitlab.com/security/ y https://www.cisa.gov/known-exploited-vulnerabilities-catalog. También es útil revisar el código fuente del motor Onigmo para comprender el componente afectado: https://github.com/k-takata/Onigmo.