Neutron, nuestro motor de IA, obtuvo un 97.1% en el benchmark CyberGym de UC Berkeley. Más información

Análisis a fondo

Análisis a fondo

RCE sin autenticación en 12 años de GitLab (CVE-2026-110264)

Un desbordamiento de entero en el compilador de expresiones regulares, CVE-2026-110264, calificado con 10.0, expone a RCE sin autenticación todos los GitLab autogestionados desde 7.0; corregido el 21 de octubre de 2026.

Resumen

  • CVE-2026-110264 es un desbordamiento de entero en el compilador de expresiones regulares de GitLab autogestionado, calificado por GitLab con CVSS v3.1 10.0, el máximo. Bajo condiciones que GitLab no ha divulgado, un atacante no autenticado puede ejecutar código arbitrario en el servidor proporcionando una expresión regular especialmente manipulada.
  • Todas las versiones autogestionadas de GitLab CE/EE desde 7.0 (2014) están afectadas, porque el fallo reside en Onigmo, el motor de expresiones regulares de Ruby, que GitLab distribuye y corrige dentro de sus propios paquetes. GitLab corrigió siete ramas a la vez el 21 de octubre de 2026, adaptando el parche a más versiones antiguas de lo que establece su política habitual.
  • No se ha comunicado explotación y el fallo no figura en el catálogo CISA KEV. No hay prueba de concepto pública y GitLab no ha publicado medidas provisionales: como las condiciones previas no se conocen, ninguna configuración permite descartar una instancia. Por tanto, actualizar es la única protección segura.
  • Actualice ahora a 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 o 18.11.13. Si aplicó el parche del 12 de octubre para CVE-2026-97229, vuelve a estar afectado: esas compilaciones están una versión de parche por debajo de las nuevas versiones corregidas.

¿Estoy afectado?

Está afectado si se cumplen ambas condiciones:

  • Ejecuta GitLab Community Edition o Enterprise Edition autogestionado, en cualquier tipo de despliegue: paquetes omnibus, Docker, charts Helm o instalaciones desde código fuente. GitLab.com ya ejecuta una versión corregida y los inquilinos GitLab Dedicated en 19.3.5-internal0 y 19.4.2-internal0 o posteriores no necesitan actuar.
  • Su versión está en un intervalo afectado. GitLab no ha dicho qué funcionalidades o ajustes necesita un atacante, por lo que ninguna instancia anterior a las versiones corregidas puede descartarse por su configuración.
Rama Versiones afectadas Versión corregida
19.5 19.5.0 19.5.1
19.4 19.4.0 a 19.4.2 19.4.3
19.3 19.3.0 a 19.3.5 19.3.6
19.2 19.2.0 a 19.2.8 19.2.9
19.1 19.1.0 a 19.1.8 19.1.9
19.0 19.0.0 a 19.0.9 19.0.10
18.11 y todas las ramas anteriores hasta 7.0 7.0 a 18.11.12 18.11.13

Compruebe la versión de todas las instancias, incluidos los servidores de preproducción y los dedicados solo a CI. En la interfaz web, la versión aparece en Ayuda y en la vista general del área de administración. En el host:

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION        # omnibus package install
docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION   # Docker: adjust the container name
cat /home/git/gitlab/VERSION                                  # source install

Las instancias que ejecutan 19.2.8, 19.3.5 o 19.4.2, la corrección del 12 de octubre para CVE-2026-97229, están dentro de los intervalos afectados y deben subir una versión de parche.

¿Cómo lo corrijo?

Actualice a la versión corregida de su rama siguiendo la ruta de actualización documentada por GitLab para instancias antiguas. Cuatro de las siete versiones corregidas, 18.11.13, 19.0.10, 19.1.9 y 19.2.9, son adaptaciones a versiones anteriores que GitLab reserva para problemas graves; su política normal solo cubre las tres versiones mensuales más recientes.

Planifique la ventana de actualización. Las versiones 19.4.3 y 19.3.6 incluyen migraciones de base de datos que se ejecutan durante la actualización, por lo que un servidor de un solo nodo permanece inactivo hasta que terminan. Las instalaciones de varios nodos pueden aplicar el parche sin interrupción mediante el procedimiento de GitLab. La versión 19.4.3 también ejecuta migraciones posteriores al despliegue.

No hay ninguna medida provisional publicada, y deben quedar claros los límites de cualquier alternativa improvisada: GitLab no ha divulgado las condiciones previas, por lo que restringir funcionalidades, registros de usuarios o uso de CI no es una defensa documentada. Limitar por red quién puede alcanzar la instancia reduce la exposición, pero no es una solución respaldada por GitLab. La protección es actualizar.

La misma publicación del 21 de octubre corrige otros 10 problemas, dos de severidad alta: CVE-2026-15723, una toma de control de cuentas mediante la búsqueda de correo para vinculación automática OmniAuth-LDAP cuando están activadas tanto la vinculación SAML como la LDAP, y CVE-2026-112212, un fallo de envenenamiento de caché en los endpoints de descubrimiento OAuth y OpenID Connect. Una sola actualización cubre todos ellos.

¿Cuál es la causa raíz?

GitLab compila expresiones regulares proporcionadas por sus usuarios. Su motor, Onigmo, contaba dos tipos de identificadores internos con contadores sin límite, por lo que un patrón con suficientes construcciones de repetición desbordaba los identificadores y corrompía el programa compilado.

GitLab es una aplicación Ruby on Rails y el motor de expresiones regulares integrado de Ruby es Onigmo, una biblioteca C. GitLab no utiliza el Ruby del sistema: incluye su propio Ruby, corregido en sus paquetes. Por eso, una debilidad de Onigmo llega a todas las versiones de GitLab desde 7.0 y GitLab distribuye la corrección parcheando el Ruby que incorpora.

El aviso de Ruby identifica con precisión el error detrás de CVE-2026-110264: «desbordamiento de identificadores internos en un patrón con muchas repeticiones». La corrección, integrada en la pull request #16801 de ruby/ruby, «Rechazar identificadores de repetición/comprobación nula desbordados en expresiones regulares enormes», muestra el mecanismo en dos líneas. Cuando Onigmo compila una repetición de rango como (?:foobar){0,100}, emite un par de instrucciones de máquina virtual que necesitan un identificador numérico:

   r = add_mem_num(reg, num_repeat); /* OP_REPEAT ID */
   reg->num_repeat++;
+  if ((MemNumType)reg->num_repeat <= 0) return ONIGERR_TOO_MANY_RANGE_REPEAT;

La línea añadida es la comprobación que faltaba. El identificador se almacena como MemNumType, definido por Onigmo como short int, un entero con signo de 16 bits y máximo de 32.767. Antes de la corrección, reg->num_repeat aumentaba indefinidamente sin compararse con ese límite, por lo que al superar 32.767 el valor escrito como identificador desbordaba y se volvía negativo. La nueva comprobación convierte el contador a MemNumType y detiene la compilación en cuanto el valor convertido es cero o negativo, antes de que un identificador desbordado llegue al programa compilado. La misma brecha existía en los identificadores de comprobación nula que Onigmo asigna al compilar construcciones que debe verificar por coincidencias vacías:

     r = add_mem_num(reg, reg->num_null_check); /* NULL CHECK ID */
     if (r) return r;
     reg->num_null_check++;
+    if ((MemNumType)reg->num_null_check <= 0) return ONIGERR_TOO_MANY_NULL_CHECK;

Un patrón manipulado con un número muy grande de estas construcciones lleva los contadores más allá del intervalo de identificadores; los valores almacenados desbordan y colisionan dentro del programa compilado. Las pruebas de regresión añadidas con la corrección muestran las dos formas desencadenantes, cada una repetida 100.000 veces en un solo patrón:

'(?:foobar){0,100}' * 100000          # range repeats
'(?:(?:foo)?|(?:bar)?)*' * 100000     # constructs needing null checks

El aviso de GitLab afirma que este desbordamiento de entero, alcanzado al compilar un patrón de ese tipo, podía convertirse en ejecución arbitraria de código en el servidor. El investigador Johan Carlsson, conocido como joaxcar, comunicó el fallo mediante el programa bug bounty de GitLab en HackerOne: fue su cuarto fallo de ejecución de código en el motor de expresiones regulares de GitLab en un mes y el primero que alcanzaba versiones anteriores a 19.2.

¿Cómo se explota?

No hay código de explotación público, por lo que los pasos siguientes se basan en el aviso, el parche original y la descripción de Ruby sobre la ruta de entrada, no en una prueba de concepto publicada.

  1. El atacante proporciona una expresión regular manipulada a una funcionalidad de GitLab que compile patrones aportados por usuarios. GitLab compila patrones de los usuarios, como los de la configuración CI, aunque no ha divulgado qué funcionalidades alcanzan este error.
  2. El patrón se genera, no se escribe a mano: repite una construcción cuantificada decenas de miles de veces, como las dos formas de las pruebas de regresión.
  3. Durante la compilación, los contadores de identificadores de repetición y comprobación nula superan el intervalo de MemNumType y desbordan, por lo que el programa compilado contiene identificadores en colisión.
  4. El estado de compilación corrupto provoca corrupción de memoria que, según GitLab, podría convertirse en ejecución de código como el proceso del servidor GitLab.

Las huellas observables de intentos de explotación o explotaciones fallidas son el objetivo de las dos reglas de detección publicadas por GitLab, ambas en su framework de detección de código abierto TLDR, escritas en formato Sigma para los registros de aplicación de GitLab.

¿Cómo se desarrolla el ataque?

El flujo es corto: un patrón generado por máquina lleno de repeticiones llega al compilador, sus identificadores desbordan y el programa corrupto provoca la caída del proceso de trabajo o entrega la ejecución al atacante.

flowchart LR A["Patrón manipulado con decenas de
miles de construcciones de repetición"] --> B["Enviado a una función de GitLab
que compila patrones del usuario"] B --> C["Onigmo asigna ID OP_REPEAT y de
comprobación nula con contadores sin límite"] C --> D["Contadores fuera del rango MemNumType:
sin control de límites, los ID desbordan"] D --> E["Los ID en colisión corrompen
el programa compilado"] E --> F["Caída del proceso o corrupción de memoria
convertida en ejecución de código"]

¿Qué puede hacer un atacante?

  • Ejecutar código arbitrario en el servidor GitLab como el usuario del proceso GitLab, sin autenticación. El vector CVSS indica alcance cambiado, por lo que la puntuación contempla impacto más allá del componente vulnerable.
  • Acceder a todo lo que puede alcanzar el proceso GitLab: repositorios e historial, variables CI/CD y otros secretos almacenados, registros de contenedores y paquetes, y el host que ejecuta la instancia.
  • Moverse a otros sistemas mediante CI: los ejecutores realizan trabajos definidos en la instancia afectada, por lo que la ejecución de código en el servidor puede influir en las cargas de trabajo y los equipos que confían en ella.

Condiciones que necesita el atacante: acceso de red a la interfaz web de GitLab y las condiciones previas no divulgadas. El vector CVSS, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, no requiere autenticación ni indica interacción del usuario. Como las condiciones previas no están publicadas, una instancia autogestionada accesible desde Internet debe considerarse expuesta.

¿Por qué funciona la corrección?

La pull request #16801 de Ruby cierra el desbordamiento en ambos contadores. Después de cada incremento, el código nuevo convierte el contador a MemNumType y devuelve un error definitivo si el valor ha desbordado:

/* regcomp.c, compile_range_repeat_node() */
if ((MemNumType)reg->num_repeat <= 0) return ONIGERR_TOO_MANY_RANGE_REPEAT;

/* regcomp.c, compile_tree_empty_check() */
if ((MemNumType)reg->num_null_check <= 0) return ONIGERR_TOO_MANY_NULL_CHECK;

Dos nuevos códigos de error, ONIGERR_TOO_MANY_RANGE_REPEAT (-224) y ONIGERR_TOO_MANY_NULL_CHECK (-225), con mensajes en regerror.c, hacen que un patrón cuyos identificadores desbordarían se rechace ahora como RegexpError antes de que exista el programa compilado. No pueden generarse identificadores en colisión, de modo que se cierra la ruta de corrupción. La corrección es completa para este fallo e incluye pruebas de regresión para ambas formas desencadenantes.

El despliegue es la parte interesante. La corrección original se integró en ruby/ruby el 29 de abril de 2026 y ninguna versión de Ruby la incluyó hasta el 23 de octubre de 2026: Ruby 4.0.9, 3.4.12 y 3.3.13, que el aviso confirma como las primeras de sus series que la contienen; Ruby 4.0.8 explícitamente no la incluye. GitLab no esperó: sus paquetes del 21 de octubre incluyen una adaptación propia del parche, que las notas de versión enumeran como «Añadir parche de desbordamiento de ID de repetición regexp de Ruby para 3.3, 3.4 y 4.0» en las compilaciones 19.2 a 19.5, junto con la corrección anterior de rango de repetición que alcanza las ramas más antiguas. Instalar una versión corregida de GitLab aplica el parche mediante el Ruby incluido.

¿Cómo compruebo si he sufrido una intrusión?

No se ha comunicado explotación de CVE-2026-110264 y no existen indicadores de compromiso. GitLab y el catálogo de CISA no muestran actividad en ataques reales a fecha del 25 de octubre de 2026.

Hasta que eso cambie, los defensores cuentan con dos reglas de detección publicadas y supervisión general:

  • Las reglas Sigma de GitLab, Caída de proceso de trabajo nativo de Onigmo y Ráfaga de errores de renderizado de Org mode, se aplican a los registros de aplicación de GitLab y son el método respaldado por el proveedor para buscar intentos de explotación.
  • En términos generales, las agrupaciones de caídas de procesos Ruby ligadas a la compilación de patrones, las ráfagas de errores de renderizado de Org mode y los procesos hijos o conexiones salientes inesperados de la cuenta del servicio GitLab son las señales que dejarían una explotación o un intento. Trate cualquier hallazgo de ese tipo como un incidente de ejecución de código: aísle, tome una instantánea, rote los secretos de la instancia y reconstruya desde una instalación limpia.

Cronología

  • 2026-04-29: se integra la corrección original, pull request #16801 de ruby/ruby, «Rechazar identificadores de repetición/comprobación nula desbordados en expresiones regulares enormes».
  • 2026-09-23: GitLab corrige en 19.4.1 los dos primeros fallos del motor de expresiones regulares de joaxcar, CVE-2026-89078 y CVE-2026-93577, ambos calificados con 9.9 y que requieren una cuenta.
  • 2026-10-12: GitLab corrige CVE-2026-97229, un desbordamiento del compilador de expresiones regulares sin autenticación y con puntuación 10.0, en 19.2.8, 19.3.5 y 19.4.2.
  • 2026-10-21: GitLab corrige CVE-2026-110264 en 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13, adaptando el parche más allá de su política habitual.
  • 2026-10-22: se publica CVE-2026-110264 con la calificación CVSS v3.1 10.0.
  • 2026-10-23: Ruby publica 4.0.9, 3.4.12 y 3.3.13 con las correcciones subyacentes de Onigmo y su aviso que identifica el error detrás de cada CVE de GitLab.
  • 2026-10-25: este artículo.

Preguntas frecuentes

Apliqué el parche del 12 de octubre para CVE-2026-97229. ¿Estoy protegido ahora?

No. Las compilaciones del 12 de octubre, 19.2.8, 19.3.5 y 19.4.2, están dentro de los intervalos afectados por CVE-2026-110264, cuyas versiones corregidas están un parche por encima, en 19.2.9, 19.3.6 y 19.4.3. El fallo anterior solo llegaba hasta 19.2; este va más atrás, por lo que toda instancia autogestionada necesita la publicación del 21 de octubre independientemente de los parches anteriores.

¿Están afectados GitLab.com o GitLab Dedicated?

No. GitLab.com ya ejecuta una versión corregida y los inquilinos GitLab Dedicated en las versiones internas 19.3.5-internal0 y 19.4.2-internal0 o posteriores ya incluyen la corrección. La exposición corresponde a instalaciones CE y EE autogestionadas de cualquier tipo de despliegue.

¿Qué funcionalidades de GitLab necesita el atacante?

GitLab no ha divulgado las condiciones previas, por lo que no existe una forma documentada de descartar una instancia por su configuración. GitLab compila expresiones regulares aportadas por usuarios, como patrones de configuración CI, y las reglas publicadas vigilan caídas de procesos Onigmo y ráfagas de errores de renderizado de Org mode. Considere expuesta cualquier instancia autogestionada accesible desde Internet hasta que esté corregida.

¿Regexp.timeout o un límite de longitud de patrón protegen mis aplicaciones Ruby?

No. El aviso de Ruby afirma que Regexp.timeout no protege contra estos errores y que los límites de longitud no son fiables porque patrones cortos pueden activar algunos. Las aplicaciones que compilen cadenas controladas por atacantes mediante Regexp.new, Regexp.union, Regexp.compile o interpolación en un literal regexp deben actualizar Ruby y dejar de compilar patrones no confiables.

¿Un escáner de CVE señalará instalaciones Ruby vulnerables?

No mediante un identificador CVE de Ruby: Ruby no ha solicitado uno, al menos por ahora, y remite a los cuatro números CVE de GitLab, cuyos registros solo nombran GitLab como producto afectado. Controle Ruby por versión: 4.0.9, 3.4.12 y 3.3.13 están corregidas; Ruby 4.0.8 carece de la corrección para CVE-2026-110264, y Ruby 3.2 y anteriores están fuera de soporte y sin corrección.

¿Qué coste tiene actualizar un servidor de un solo nodo?

Las versiones 19.4.3 y 19.3.6 incluyen migraciones de base de datos que deben terminar antes de iniciar GitLab, lo que implica inactividad en una instalación de un solo nodo. Las instalaciones de varios nodos pueden aplicar el parche con el procedimiento sin interrupción de GitLab; además, 19.4.3 ejecuta migraciones posteriores al despliegue tras la actualización.

Encuentre instancias GitLab sin parchear antes que los atacantes

Escanee sus activos externos e imágenes de contenedor con Ostorlab para identificar cada instancia GitLab autogestionada de su infraestructura que siga ejecutando una versión anterior a las publicadas el 21 de octubre de 2026, incluidos los servidores de preproducción y exclusivos de CI que rara vez reciben atención.

Referencias

  • Publicación de parches críticos de GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13, 21 de octubre de 2026, con la descripción de CVE-2026-110264, vector CVSS 10.0, intervalos afectados, nota de adaptación a versiones anteriores, reconocimiento a joaxcar, enlaces de detección y advertencias sobre migraciones: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/ (consultado el 25 de octubre de 2026)
  • Registro CVE-2026-110264 con los intervalos de versiones afectadas y la referencia al informe de HackerOne: https://cveawg.mitre.org/api/cve/CVE-2026-110264 (consultado el 25 de octubre de 2026)
  • Aviso de Ruby, «Correcciones de compilación regexp relacionadas con CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 y CVE-2026-110264 de GitLab», 23 de octubre de 2026, con la tabla de errores por CVE, definición de entrada afectada, límites de las medidas provisionales y reconocimientos: https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/ (consultado el 25 de octubre de 2026)
  • Pull request #16801 de ruby/ruby, «Rechazar identificadores de repetición/comprobación nula desbordados en expresiones regulares enormes», integrada el 29 de abril de 2026, con las dos comprobaciones de contadores, los nuevos códigos de error y las pruebas de regresión: https://github.com/ruby/ruby/pull/16801 (consultado el 25 de octubre de 2026)
  • Versión Ruby 4.0.9, 23 de octubre de 2026, primera versión 4.0 con la corrección CVE-2026-110264: https://www.ruby-lang.org/en/news/2026/10/23/ruby-4-0-9-released/ (consultado el 25 de octubre de 2026)
  • Versiones Ruby 3.4.12 y 3.3.13, 23 de octubre de 2026: https://www.ruby-lang.org/en/news/2026/10/23/ruby-3-4-12-released/ y https://www.ruby-lang.org/en/news/2026/10/23/ruby-3-3-13-released/ (consultado el 25 de octubre de 2026)
  • Merge request de GitLab omnibus que añade el parche de desbordamiento de ID de repetición regexp de Ruby a la compilación 19.5, desde la lista de correcciones de la versión: https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/9922 (consultado el 25 de octubre de 2026)
  • Regla de detección de GitLab «Caída de proceso de trabajo nativo de Onigmo», formato Sigma, en el framework TLDR: https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/onigmo_native_worker_crash.md (consultado el 25 de octubre de 2026)
  • Regla de detección de GitLab «Ráfaga de errores de renderizado de Org mode», formato Sigma, en el framework TLDR: https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/org_mode_render_error_burst.md (consultado el 25 de octubre de 2026)
  • Informe HackerOne de CVE-2026-110264, referencia 4093475: https://hackerone.com/reports/4093475 (referenciado desde el registro CVE, consultado el 25 de octubre de 2026)
  • The Hacker News, «Un fallo crítico de GitLab (CVSS 10.0) podría permitir RCE sin autenticación en 12 años de versiones», 21 de octubre de 2026, con la matriz de versiones corregidas, la nueva exposición de quienes aplicaron el parche del 12 de octubre y el detalle de inactividad al actualizar: https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html (consultado el 25 de octubre de 2026)
  • The Hacker News, «Ruby corrige tres errores del motor de expresiones regulares responsables de cuatro fallos RCE críticos de GitLab», 23 de octubre de 2026: https://thehackernews.com/2026/10/ruby-fixes-three-regex-engine-bugs.html (consultado el 25 de octubre de 2026)
  • CVE-2026-97229, fallo complementario del 12 de octubre corregido en 19.2.8, 19.3.5 y 19.4.2: https://www.cve.org/CVERecord?id=CVE-2026-97229 (consultado el 25 de octubre de 2026)
  • Documentación de actualización sin interrupción de GitLab: https://docs.gitlab.com/update/zero_downtime/ (consultado el 25 de octubre de 2026)
  • Rutas de actualización de GitLab para versiones antiguas: https://docs.gitlab.com/update/ (consultado el 25 de octubre de 2026)
  • Catálogo CISA Known Exploited Vulnerabilities, consultado para estos CVE el 25 de octubre de 2026 (no incluidos): https://www.cisa.gov/known-exploited-vulnerabilities-catalog