Destinatarios: administradores que ejecutan GitLab en sus propios servidores o en la nube (autogestionado), y desarrolladores que construyen aplicaciones en Ruby. Esta página se basa en el aviso de publicación de parches de GitLab, en el anuncio oficial de Ruby, en la Base Nacional de Datos de Vulnerabilidades (NVD) de Estados Unidos y en los datos públicos de CISA. No explica cómo funcionan los ataques.
続報待ち：この記事は公式発表に合わせて更新します
a las 08:00 JST, 25 de octubre de 2026まだ分かっていないこと
- Las condiciones exactas en las que se puede activar la falla (GitLab solo dice «bajo ciertas condiciones»)
- Cualquier cambio en el estado de explotación (no se informó ninguno en el momento de la divulgación)
- La evaluación propia de la NVD (en análisis)
GitLab publicó la versión de parche el 21 de octubre, y el equipo de Ruby publicó las versiones corregidas el 23 de octubre. No se ha informado de explotación y la falla no figura en el catálogo KEV de CISA. GitLab indica que los detalles se harán públicos 90 días después de la publicación. Esta página se actualizará si cambia la situación.
Qué hacer hoy (GitLab autogestionado)
Compruebe la versión
En una instalación con paquete Linux (Omnibus), ejecute sudo gitlab-rake gitlab:env:info en un nodo que ejecute GitLab Rails; la versión aparece en la sección «GitLab information». También puede verla en el área de administración si inicia sesión como administrador. En configuraciones de varios nodos, revise cada nodo.
Pase a la versión corregida de la misma línea
Si está en 19.4.x, vaya a 19.4.3; si está en 19.3.x, vaya a 19.3.6, y así sucesivamente. En opinión de este sitio, una actualización de parche dentro de la misma línea menor normalmente no implica paradas de actualización (verifíquelo con la herramienta de GitLab). GitLab indica que las instancias de un solo nodo deben esperar tiempo de inactividad, porque GitLab no arranca hasta que terminan las migraciones. Las instancias de varios nodos pueden usar el procedimiento de actualización sin tiempo de inactividad.
Desde versiones antiguas, revise primero las paradas de actualización
GitLab define paradas obligatorias de actualización que no deben saltarse. A octubre de 2026, la lista incluye 18.2, 18.5, 18.8 y 18.11 para GitLab 18, y 19.2, 19.5, 19.8 y 19.11 para GitLab 19 (de las paradas de GitLab 19, la 19.2 y la 19.5 ya están publicadas). Introduzca sus versiones actual y de destino en la herramienta Upgrade Path de GitLab para obtener las versiones por las que debe pasar. GitLab indica que debe actualizar a estas versiones antes que a las posteriores, y esperar a que terminen las migraciones en segundo plano en cada parada.
Si no puede actualizar de inmediato, restrinja quién puede acceder
El aviso de GitLab no ofrece otra solución alternativa que actualizar. Hasta que actualice, este sitio recomienda mantener GitLab inaccesible desde fuera de su red con un cortafuegos o una VPN, y desactivar los nuevos registros. Ninguna de estas medidas cierra el fallo, así que mantenga avanzada la actualización.
Busque rastros
GitLab ha publicado dos detecciones de amenazas para clientes autogestionados (la sección «Detecting CVE-2026-110264 Exploitation Attempts» del aviso). Si tiene monitorización de registros, cárguelas. Busque también procesos, archivos, cuentas de administrador y conexiones salientes que no reconozca. Consulte cómo comprobar si su servidor fue comprometido.
¿Estoy afectado? Tabla rápida
| Lo que ejecuta | CVE-2026-110264 (Crítica) | Fallas de gravedad alta y otras de la misma versión | Destino |
|---|---|---|---|
| 19.5.x anterior a 19.5.1 | Afectada | Afectada | 19.5.1 |
| 19.4.x anterior a 19.4.3 | Afectada | Afectada | 19.4.3 |
| 19.3.x anterior a 19.3.6 | Afectada | Afectada | 19.3.6 |
| 19.0.x a 19.2.x | Afectada (corregida en 19.0.10, 19.1.9, 19.2.9) | Corregidas solo en 19.3.6 y posteriores | 19.3.6 o posterior |
| 18.11.x anterior a 18.11.13 | Afectada (corregida en 18.11.13) | Corregidas solo en 19.3.6 y posteriores | 19.3.6 o posterior |
| 18.10 y anteriores (desde 7.0) | Afectada | Depende de la falla | Versión más reciente mediante las paradas de actualización |
| GitLab.com | Parcheada | Parcheada | Sin acción |
| GitLab Dedicated | Parcheada desde 19.3.5-internal0, 19.4.2-internal0 | Igual | Sin acción, según GitLab |
El rango afectado difiere para cada una de las otras fallas (por ejemplo, CVE-2026-15723 empieza en 10.1 y CVE-2026-112212 en 18.3). Consulte la tabla del aviso de GitLab para los rangos exactos.
Versión actual
Antes de la corrección, la falla crítica permanece
18.11.13 a 19.2.9
Crítica corregida, fallas de gravedad alta permanecen
19.3.6 / 19.4.3 / 19.5.1
Todas las correcciones de esta versión
Qué se divulgó (según el aviso de GitLab)
- CVE
- CVE-2026-110264 (CWE-190: desbordamiento de entero)
- Gravedad
- Crítica, CVSS v3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, calificación de GitLab)
- Problema
- Bajo ciertas condiciones, un desbordamiento de entero al compilar una expresión regular especialmente diseñada podría permitir a un usuario no autenticado ejecutar código arbitrario en el servidor de GitLab
- Afectadas
- GitLab CE/EE desde 7.0, anteriores a 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 y 19.5.1
- Ya corregidas
- GitLab.com; GitLab Dedicated desde 19.3.5-internal0 y 19.4.2-internal0
- Reportada por
- Un investigador externo, a través del programa de recompensas por errores de GitLab en HackerOne
- Explotación
- No indicada en el aviso; no figura en el catálogo KEV de CISA a fecha del 25 de octubre
La misma versión corrige otras 11 vulnerabilidades, dos de ellas de gravedad alta. CVE-2026-15723 (CVSS 8.2) podría permitir a un usuario autenticado tomar el control de una cuenta existente respaldada por LDAP cuando están habilitados a la vez OmniAuth SAML y el enlace automático de LDAP. CVE-2026-112212 (CVSS 7.5) podría permitir envenenar el documento de descubrimiento OAuth/OIDC en caché, de modo que ciertos flujos se envíen a un servidor externo. Las demás son cinco de gravedad media y cuatro de gravedad baja.
La evaluación SSVC de CISA con fecha del 21 de octubre indica explotación «none», automatizable «yes» e impacto técnico «total». Terminar la actualización mientras no se informe de explotación es la forma más económica de resolver esto (opinión de este sitio).
La causa raíz está en el motor de expresiones regulares de Ruby: para desarrolladores de Ruby
El 23 de octubre, el equipo de Ruby publicó Ruby 4.0.9, 3.4.12 y 3.3.13, que corrigen fallos en el motor de expresiones regulares de Ruby (Onigmo). Corrigen tres fallos relacionados con cuatro CVE asignadas por GitLab (CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 y CVE-2026-110264). Los tres CVE distintos de CVE-2026-110264 se corrigieron en GitLab 19.4.1 y 19.4.2.
Regexp.timeout no ayuda
Según el anuncio de Ruby, los fallos solo se alcanzan cuando una aplicación compila una regexp a partir de una cadena que controla un atacante (Regexp.new, Regexp.union, Regexp.compile, o interpolación como /#{input}/). Las aplicaciones que usan únicamente expresiones regulares escritas por el desarrollador no están afectadas. Regexp.timeout no protege contra estos fallos, y limitar la longitud del patrón tampoco es fiable.
Ruby 3.3 está en mantenimiento solo de seguridad, pero 3.3.13 incluye estas correcciones como excepción porque GitLab asignó CVE a problemas que dependen de ellas. Ruby 3.2 llegó al fin de su vida útil el 1 de abril de 2026 y no tiene una versión corregida.
Los paquetes Linux y las imágenes cloud native de GitLab incluyen los propios parches de expresiones regulares de GitLab, así que los administradores de GitLab actualizan GitLab en sí, no el Ruby del servidor. Si instaló GitLab desde el código fuente, este sitio recomienda actualizar también ese Ruby a una versión corregida.
Patrones riesgosos
- Pasar directamente a Regexp.new el texto de un cuadro de búsqueda o de un filtro
- Ejecutar patrones que los usuarios registran como expresiones regulares del servidor
- Suponer que Regexp.timeout o un límite de longitud lo hace seguro
- Seguir en Ruby 3.2 o anterior después del fin de su vida útil
Patrones más seguros
- Para búsquedas de texto simple, use Regexp.escape para que la entrada se compare literalmente
- Pregúntese si es realmente necesario que los usuarios escriban expresiones regulares
- Si lo es, ejecútelas con otro motor de expresiones regulares o en un proceso aislado (opinión de este sitio)
- Actualice Ruby a 4.0.9, 3.4.12 o 3.3.13 o posterior
No se puede saber solo con su propio código si una gema o framework del que depende construye expresiones regulares a partir de la entrada del usuario, así que actualizar Ruby es la solución más fiable. Para vigilar las dependencias, consulte cómo monitorear las CVE de dependencias con osv-scanner.
Lo que suelen olvidar los servidores Git autoalojados
Ejecutar GitLab usted mismo elimina algunos accidentes, como un repositorio hecho público por error, pero la tarea de aplicar parches pasa a ser suya. Con una falla que se remonta a la 7.0, los servidores que dejaron de actualizarse hace tiempo tienen más paradas de actualización que pasar y el trabajo más pesado.
Opinión de este sitio: manténgase, en tiempos normales, al menos una parada por detrás de la última parada obligatoria de actualización. Así, una actualización de emergencia son uno o dos pasos, no una cadena larga. Para las ventajas y desventajas del autoalojamiento, consulte Git autoalojado frente a GitHub: cuál es más seguro.
Lo que aún se desconoce
| Elemento | Estado |
|---|---|
| Las condiciones exactas de la falla | No indicadas («bajo ciertas condiciones»; detalles que se publicarán 90 días después de la versión) |
| Explotación | No indicada (no figura en el KEV de CISA a fecha del 25 de octubre) |
| Código de explotación público | No indicado |
| Evaluación de la NVD | En análisis (la calificación de GitLab es 10.0) |
| CVE para los propios fallos de Ruby | Aún no solicitadas por el equipo de Ruby (podrían revisarse) |
Fuentes
- GitLab, «GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13» (21 de octubre de 2026) — docs.gitlab.com
- Ruby, «Regexp compilation fixes related to GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264» (23 de octubre de 2026) — ruby-lang.org
- Ruby, «Ruby Maintenance Branches» — ruby-lang.org
- GitLab, «Upgrade paths» — docs.gitlab.com
- GitLab, «Maintenance Rake tasks» (gitlab:env:info) — docs.gitlab.com
- NIST NVD, «CVE-2026-110264» — nvd.nist.gov
- CISA, «Known Exploited Vulnerabilities Catalog» — cisa.gov
Registro de cambios
2026-10-25: Primera versión, basada en el aviso de publicación de parches de GitLab, el anuncio oficial de Ruby, la NVD y el catálogo KEV de CISA (versión del 23 de octubre de 2026).
Lectura siguiente
- Ventajas y desventajas del autoalojamiento: Git autoalojado frente a GitHub: cuál es más seguro
- Priorización: Cómo decidir qué CVE corregir primero (CVSS, EPSS, KEV)
- Comprobación de compromiso: Cómo comprobar si su servidor fue comprometido
- Otra corrección de runtime la misma semana: Vulnerabilidades de PHP CVE-2026-109618 y CVE-2026-109619
- Términos: Qué es RCE (ejecución remota de código) / Qué es CVSS