Ruby corrige tres fallos del motor regex Onigmo, origen de cuatro vulnerabilidades RCE críticas en GitLab

Ruby ha publicado las versiones 4.0.9, 3.4.12 y 3.3.13 para cerrar tres fallos de seguridad de memoria en Onigmo, el motor de expresiones regulares integrado en el lenguaje. Esos mismos fallos son la causa de cuatro vulnerabilidades críticas de ejecución remota de código (RCE) que GitLab corrigió entre finales de septiembre y finales de octubre de 2026.

Qué ha pasado

Los fallos se encuentran en la fase en la que Ruby compila una expresión regular. Un patrón especialmente diseñado puede corromper la memoria durante la compilación y, en determinadas condiciones, esa corrupción puede convertirse en ejecución de código en el servidor.

GitLab fue el primero en toparse con el problema porque compila patrones que aportan sus propios usuarios, por ejemplo, expresiones regulares dentro de la configuración de CI/CD. Lo corrigió en su producto en cuatro ocasiones, cada vez incluyendo una copia parcheada de Ruby:

Dos CVE publicados el 23 de septiembre: ambos requieren una cuenta autenticada y tienen una puntuación CVSS de 9,9.
CVE-2026-97229 (12 de octubre) y CVE-2026-110264 (21 de octubre): ambos son alcanzables sin autenticación y obtienen la puntuación máxima, 10,0. CVE-2026-110264 afecta a todas las versiones de GitLab desde la 7.0.

A 23 de octubre, ninguno de los cuatro figuraba en el catálogo Known Exploited Vulnerabilities de CISA, y no nos consta explotación confirmada en entornos reales.

Por qué importa más allá de GitLab

Es un problema de Ruby, no solo de GitLab. Cualquier aplicación Ruby está expuesta si construye una expresión regular a partir de una cadena que controla un atacante; por ejemplo, si pasa datos del usuario a Regexp.new, Regexp.union o Regexp.compile, o si los interpola en un patrón literal como /#{input}/. Las aplicaciones que solo usan expresiones regulares escritas por sus propios desarrolladores no están afectadas.

Dos mitigaciones aparentemente lógicas no sirven aquí:

Regexp.timeout limita cuánto dura la coincidencia, pero estos fallos se activan durante la compilación, antes de que se aplique ningún tiempo límite.
Limitar la longitud del patrón no es fiable, porque bastan patrones cortos para activar los fallos.

También hay un punto ciego para los equipos de defensa. Ruby no ha solicitado, de momento, identificadores CVE propios para estas correcciones y remite a los usuarios a los cuatro CVE de GitLab. Esos registros solo mencionan GitLab como producto afectado, así que un escáner que cruce datos CVE con las versiones de Ruby instaladas no encontrará nada que señalar. La documentación de Ruby sigue tratando los patrones no confiables principalmente como un riesgo de denegación de servicio, aunque el proyecto ya ha emitido CVE por fallos similares del motor en el pasado.

Qué hacer

Para aplicaciones Ruby:

Actualice: Ruby 4.0 → 4.0.9, Ruby 3.4 → 3.4.12, Ruby 3.3 → 3.3.13. La versión 4.0.8, publicada esa misma semana, no incluye una de las correcciones, así que pase directamente a la 4.0.9. Las versiones 3.4.12 y 3.3.13 son las primeras de sus ramas con alguna de las tres correcciones.
Ruby 3.2 y anteriores no recibirán parche: la 3.2 llegó al final de su vida útil el 1 de abril de 2026. Planifique la migración a 3.4 o 4.0.
Hasta que pueda actualizar, deje de compilar expresiones regulares a partir de entradas no confiables. Busque en su código Regexp.new, Regexp.union, Regexp.compile y patrones interpolados que reciban datos de las peticiones.
No confíe en las alertas de dependencias basadas en CVE para este caso: compruebe directamente la versión de Ruby, incluida la que viene dentro de sus imágenes de contenedor.

Para GitLab autogestionado:

Instale una versión que corrija CVE-2026-110264: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 o 18.11.13. Como GitLab incluye su propio Ruby, actualizar GitLab aplica la corrección.
GitLab.com ya está parcheado, y los clientes de GitLab Dedicated con versiones internas recientes no necesitan hacer nada.
Utilice las reglas de detección publicadas por GitLab para revisar los registros en busca de intentos de explotación, sobre todo en instancias expuestas a internet.

Este tipo de fallos vive en el hueco entre su código y el entorno de ejecución que hay debajo, justo donde los avisos CVE se quedan en silencio. Nuestra revisión de código asistida por IA rastrea por dónde llegan los datos controlados por el usuario a operaciones peligrosas como la compilación dinámica de expresiones regulares, para detectar esta clase de problemas en su propio código y no solo cuando un proveedor publica un aviso.