El equipo de desarrollo de Ruby liberó las versiones 4.0.9, 3.4.12 y 3.3.13 con el objetivo de cerrar tres defectos en Onigmo, el motor de expresiones regulares que forma parte del lenguaje. Esos mismos defectos están en la raíz de cuatro vulnerabilidades críticas de ejecución remota de código (RCE) que GitLab ha ido corrigiendo a lo largo del último mes.
Los análisis de GitLab determinaron que un patrón manipulado deliberadamente podía corromper la memoria durante la fase de compilación de la expresión regular en Ruby, lo que abría la puerta a ejecutar código arbitrario en sus servidores. El aviso de Ruby subraya que el problema no se limita a GitLab: cualquier aplicación que construya una expresión regular usando texto bajo control de un atacante queda expuesta.
Alcance real del problema
De acuerdo con el comunicado de Ruby, una aplicación solo está en riesgo cuando compila una expresión regular a partir de una cadena que un atacante puede manipular. Eso sucede cuando el programa entrega esa cadena a Regexp.new, Regexp.union o Regexp.compile, o cuando la incrusta dentro de un patrón mediante interpolación, por ejemplo /#{input}/. En cambio, las aplicaciones que únicamente emplean expresiones regulares escritas por sus propios desarrolladores quedan fuera del riesgo.
Las correcciones ya están disponibles en las versiones 4.0.9, 3.4.12 y 3.3.13. Cabe precisar que 3.4.12 y 3.3.13 son las primeras entregas de sus respectivas ramas que incorporan alguna de las tres reparaciones.
- Ruby 4.0: actualizar a 4.0.9
- Ruby 3.4: actualizar a 3.4.12
- Ruby 3.3: actualizar a 3.3.13
La versión 4.0.8, publicada apenas unos días antes, no contenía el parche para una de las vulnerabilidades, identificada como CVE-2026-110264, de modo que quienes operan la rama 4.0 deben migrar a 4.0.9 sin excepción. Las ramas 3.2 y anteriores ya no recibirán soporte: Ruby 3.2 llegó al final de su ciclo de vida el 1 de abril de 2026 y 3.2.11 fue su última entrega. La recomendación oficial es pasar a 3.4 o a 4.0.
Para quienes no puedan actualizar de inmediato, el aviso sugiere suspender la compilación de expresiones regulares a partir de entradas no confiables. También advierte sobre dos medidas que aparentan proteger pero no funcionan: fijar Regexp.timeout no frena estos fallos y limitar la longitud del patrón tampoco es confiable, porque patrones muy cortos pueden disparar los errores.
Cómo llegaron los fallos a GitLab
GitLab compila expresiones regulares que provienen de sus propios usuarios, como los patrones definidos en una configuración de CI/CD. La compañía detectó que patrones manipulados podían corromper la memoria mientras Ruby los compilaba y emitió cuatro CVE entre el 23 de septiembre y el 21 de octubre, aplicando cada corrección mediante el despliegue de una versión parcheada de Ruby.
Los dos primeros, divulgados el 23 de septiembre, exigen una cuenta autenticada y recibieron una calificación de 9.9 sobre 10. Los dos de octubre, CVE-2026-97229 el día 12 y CVE-2026-110264 el día 21, no requieren cuenta y alcanzaron 10.0, la puntuación máxima. CVE-2026-110264 alcanza a todas las versiones de GitLab desde la 7.0 en adelante.
Un investigador que usa el seudónimo joaxcar reportó los cuatro fallos mediante el programa de recompensas por errores de GitLab. Al 23 de octubre, ninguno figuraba en el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA.
Sin CVE de Ruby, por ahora
Ruby no ha solicitado identificadores CVE propios para estas correcciones, "al menos por ahora", según indicó, y pidió a los usuarios seguir el asunto a través de los cuatro números CVE de GitLab. Esa decisión genera un punto ciego para cualquier herramienta de escaneo basada en CVE: los registros de GitLab solo identifican a GitLab como producto afectado, por lo que un escáner que cruce esos datos con las versiones de Ruby instaladas no encuentra coincidencia alguna.
En el pasado, Ruby sí trató este tipo de error como una vulnerabilidad y asignó CVE a correcciones en 2022 y 2024, aunque durante mucho tiempo ha sido considerado inseguro construir una expresión regular a partir de entradas no confiables. Su documentación aún describe los patrones no confiables únicamente como un riesgo de denegación de servicio. Ruby aseguró que actualizará su aviso si decide solicitar algún identificador CVE.
Recomendaciones para administradores de GitLab
Las instancias autogestionadas de GitLab necesitan la versión que corrige CVE-2026-110264. GitLab la publicó el 21 de octubre y la aplicó de forma retroactiva hasta la versión 18.11.13. Las versiones corregidas son las siguientes:
- 19.5.1
- 19.4.3
- 19.3.6
- 19.2.9
- 19.1.9
- 19.0.10
- 18.11.13
GitLab.com ya opera con la versión parcheada, y los inquilinos de GitLab Dedicated que corren versiones internas recientes no requieren acción, según la compañía. Dado que GitLab incluye su propia copia de Ruby y la parchea, instalar una de estas versiones corregidas deja aplicada la solución. GitLab también publicó reglas de detección que los administradores autogestionados pueden usar para buscar indicios de intentos de explotación.
Deja una respuesta