Cuatro vulnerabilidades RCE en GitLab obligan a actualizar Ruby; parches ya disponibles para tres ramas

Los desarrolladores de Ruby lanzaron las versiones 4.0.9, 3.4.12 y 3.3.13 tras cuatro vulnerabilidades en GitLab que permitían ejecutar código arbitrario en el servidor mediante expresiones regulares especialmente preparadas. Detrás de los cuatro CVE hay tres errores en el motor Onigmo, integrado en Ruby, y dos de ellos fueron valorados por GitLab con 10 puntos sobre 10.

GitLab permite a los usuarios especificar expresiones regulares, por ejemplo en la configuración de CI/CD. Esas plantillas ayudan al programa a buscar y verificar texto según reglas dadas. Como explicaron los desarrolladores de Ruby, una cadena especialmente elaborada podía dañar la memoria ya durante la compilación del patrón. En GitLab, el mecanismo vulnerable permitía llevar el error hasta ejecución remota de código y obligar al servidor a ejecutar comandos del atacante.

El primer problema, CVE-2026-89078, provocaba una liberación doble de la misma área de memoria si el motor no podía analizar un determinado patrón. CVE-2026-93577 y CVE-2026-97229 explotaban otro error: al calcular el tamaño de la expresión compilada se producía un desbordamiento de enteros. En este caso, los dos identificadores CVE ocultan un único defecto de Ruby.

CVE-2026-110264 afectaba a identificadores internos de Onigmo. Si un atacante especificaba demasiadas repeticiones dentro de la expresión, el contador podía desbordarse y dañar la gestión de memoria. GitLab evaluó la vulnerabilidad en los máximos 10 puntos en CVSS. Para el ataque no se requería una cuenta, y las versiones vulnerables de GitLab existían desde la rama 7.0.

Dos vulnerabilidades anteriores, CVE-2026-89078 y CVE-2026-93577, requerían autorización y recibieron 9,9 puntos cada una. Más tarde GitLab cerró CVE-2026-97229 con una puntuación de 10,0, que ya permitía atacar el servidor sin iniciar sesión. La compañía publicó correcciones para sus propios productos antes, introduciendo cambios en la versión de Ruby incluida con GitLab.

Ahora las correcciones han llegado al propio lenguaje. Ruby 4.0 ya contenía parte de los cambios de protección: la versión 4.0.0 eliminó la liberación doble de memoria, y la 4.0.8 cerró el desbordamiento al calcular el tamaño del patrón. Ruby 4.0.9 añadió la corrección restante. Para las ramas 3.4 y 3.3, el conjunto completo de correcciones apareció en las versiones 3.4.12 y 3.3.13.

El peligro no amenaza a todas las aplicaciones en Ruby. El problema aparece cuando un programa toma una cadena de una fuente no confiable y la convierte en una expresión regular mediante Regexp.new, Regexp.union, Regexp.compile o inserta los datos del usuario directamente en el patrón. Si todas las expresiones fueron escritas de antemano por los desarrolladores y el usuario no puede modificar su contenido, los errores descritos no se activan.

Configurar Regexp.timeout tampoco salva. La limitación controla el tiempo de búsqueda de coincidencias, mientras que la memoria se daña antes, durante la compilación de la expresión. Limitar la longitud de la cadena no es suficiente: algunos errores provocan problemas incluso con patrones cortos. Los desarrolladores recomiendan actualizar a Ruby 4.0.9, 3.4.12 o 3.3.13, y hasta la actualización no convertir la entrada no confiable en expresiones regulares.

Aún no hay CVE separados para los tres errores de Ruby. El equipo del lenguaje se propone decidir si la compilación de expresiones regulares no confiables debe considerarse un escenario soportado que requiera su propia clasificación de vulnerabilidades. De momento, para rastrear los problemas los desarrolladores proponen usar los cuatro identificadores asignados por GitLab.