Ruby soluciona tres errores en el motor de expresiones regulares responsables de cuatro vulnerabilidades críticas de RCE en GitLab.

⟫ 23/10/2026 ⟫ info@thehackernews.com (The Hacker News)

Fuente: The Hacker News

El lenguaje de programación Ruby ha lanzado recientemente las versiones 4.0.9, 3.4.12 y 3.3.13 con el objetivo de corregir tres errores en Onigmo, el motor de expresiones regulares integrado en el lenguaje. Estos errores son responsables de cuatro vulnerabilidades críticas de seguridad que GitLab ha parcheado en el transcurso del último mes. La importancia de estas actualizaciones radica en que afectan a cualquier aplicación que construya expresiones regulares a partir de texto controlado por un atacante, y no se limitan únicamente a la plataforma de GitLab.

GitLab identificó que un patrón especialmente diseñado podía corromper la memoria durante el proceso de compilación de Ruby, lo que podría llevar a la ejecución de código en sus propios servidores. Este tipo de vulnerabilidad (CVE-2026-110264, entre otras) resalta la necesidad urgente de que los desarrolladores y administradores de sistemas revisen cómo manejan las expresiones regulares en sus aplicaciones para evitar que sean víctimas de ataques.

En su aviso, Ruby especificó que se considera afectada cualquier aplicación que compila una expresión regular a partir de una cadena de texto controlada por un atacante. Esto ocurre cuando un programa pasa dicha cadena a métodos como `Regexp.new`, `Regexp.union` o `Regexp.compile`, o cuando se utiliza interpolación para incluirla dentro de un patrón, como en `/#{input}/`. Las aplicaciones que solo utilizan expresiones regulares escritas por sus propios desarrolladores no están en riesgo.

Las versiones 4.0.9, 3.4.12 y 3.3.13 de Ruby corrigen los fallos de seguridad mencionados. Las versiones 3.4.12 y 3.3.13 son las primeras de sus respectivas series en incluir alguna de las tres correcciones. Es relevante mencionar que una versión anterior, la 4.0.8, no incluye la solución para una de las vulnerabilidades, específicamente CVE-2026-110264, por lo que los usuarios de Ruby 4.0 deberían actualizar a la versión 4.0.9. Por otro lado, Ruby 3.2 y versiones anteriores no recibirán parches, ya que Ruby 3.2 alcanzó su fin de vida el 1 de abril de 2026, siendo la versión 3.2.11 la última publicada. Ruby recomienda encarecidamente a los usuarios que migren a la versión 3.4 o 4.0.

Para aquellos que no puedan realizar la actualización de inmediato, el aviso de Ruby sugiere dejar de compilar expresiones regulares a partir de entradas no confiables. Curiosamente, dos defensas que podrían parecer útiles no lo son. Establecer un `Regexp.timeout` no detiene estos errores, y limitar la longitud de un patrón resulta poco fiable, ya que patrones cortos también pueden desencadenar las vulnerabilidades.

GitLab compila expresiones regulares proporcionadas por sus usuarios, como los patrones en una configuración de CI/CD, y descubrió que patrones manipulados podrían corromper la memoria durante su compilación. Entre el 23 de septiembre y el 21 de octubre, GitLab emitió cuatro CVEs, solucionando cada uno mediante el lanzamiento de una versión de Ruby corregida. Los dos primeros CVEs, divulgados el 23 de septiembre, requieren una cuenta de usuario y fueron calificados con un 9.9 sobre 10. Los otros dos, CVE-2026-97229 del 12 de octubre y CVE-2026-110264 del 21 de octubre, no requieren ninguna cuenta y obtuvieron la máxima calificación de 10.0. Es importante señalar que CVE-2026-110264 afecta a todas las versiones de GitLab desde la 7.0 en adelante.

Un investigador que opera bajo el seudónimo de joaxcar reportó los cuatro fallos a través del programa de recompensas por errores de GitLab. Hasta el 23 de octubre, ninguno de estos cuatro CVEs estaba listado en el catálogo de Vulnerabilidades Conocidas y Explotadas de CISA. Ruby no ha solicitado identificadores CVE propios para estas correcciones "al menos por ahora", y ha indicado a los usuarios que sigan los problemas utilizando los cuatro números CVE de GitLab.

Esta situación genera un vacío para aquellos que escanean por CVE. Los registros de CVE de GitLab solo nombran a GitLab como el producto afectado, lo que significa que un escáner que verifique esos registros contra versiones de Ruby instaladas no tendrá coincidencias. Ruby ha tratado este tipo de errores como vulnerabilidades en el pasado, asignando números CVE a las correcciones en 2022 y 2024, a pesar de que durante mucho tiempo ha sido inseguro construir expresiones regulares a partir de entradas no confiables. Su documentación sigue describiendo los patrones no confiables únicamente como un riesgo de denegación de servicio. Ruby ha afirmado que actualizará su aviso si solicita algún identificador CVE.

Para los casos de instancias autogestionadas de GitLab, es crucial contar con la versión que corrige CVE-2026-110264. GitLab la lanzó el 21 de octubre y ha retroportado la corrección hasta la versión 18.11.13. GitLab.com ya opera la versión corregida, y los inquilinos de GitLab Dedicated en lanzamientos internos recientes no necesitan tomar ninguna medida, dado que GitLab incluye su propia copia de Ruby y la ha parcheado allí, lo que implica que la instalación de cualquiera de estas versiones corregidas aplica la solución.

Además, GitLab ha publicado reglas de detección que los administradores autogestionados pueden utilizar para buscar señales de intentos de explotación, lo que subraya la importancia de estar alerta y actuar proactivamente ante posibles amenazas de seguridad.

◢ VULNERABILIDADES ◣

Ruby Fixes Three Regex Engine Bugs Responsible for Four Critical GitLab RCE Flaws

⟫ 23/10/2026 ⟫ info@thehackernews.com (The Hacker News)

Source: The Hacker News

Ruby has released versions 4.0.9, 3.4.12, and 3.3.13 to fix three bugs in Onigmo, the regular expression engine built into the language. The bugs lie behind four critical security flaws that GitLab patched over the past month. GitLab found that a specially crafted pattern could corrupt memory while Ruby compiles it, potentially leading to code execution on its own servers. Ruby says any application that builds a regular expression from text an attacker controls is affected, not just GitLab. Inits advisory, Ruby said an application is affected only if it compiles a regular expression from a string an attacker controls. That happens when a program passes such a string to Regexp.new, Regexp.union or Regexp.compile, or places it inside a pattern through interpolation, as in /#{input}/. Applications that only use regular expressions written by their own developers are not affected. Ruby fixed the bugs in 4.0.9, 3.4.12, and 3.3.13. The 3.4.12 and 3.3.13 releases are the first in their series to carry any of the three fixes. An earlier release from the same week, 4.0.8, does not include the fix for one of the flaws,CVE-2026-110264, so 4.0 users should install 4.0.9. Ruby 3.2 and earlier will not get a fix. Ruby 3.2reached end of lifeon April 1, 2026, and 3.2.11 was its final release. Ruby recommends moving to 3.4 or 4.0. If you cannot upgrade yet, the advisory says to stop compiling regular expressions from untrusted input. Two defenses that look like they would help do not. Setting Regexp.timeout does not stop these bugs. Capping the length of a pattern is also unreliable because short patterns can trigger bugs. GitLab compiles regular expressions supplied by its users, such as the patterns in a CI/CD configuration. It found that crafted patterns could corrupt memory as Ruby compiled them, and it issued four CVEs betweenSeptember 23andOctober 21, fixing each by shipping a patched Ruby. The first two, disclosed on September 23, each need a logged-in account and were rated 9.9 out of 10. The two fromOctober,CVE-2026-97229on the 12th and CVE-2026-110264 on the 21st, need no account and were rated 10.0, the maximum. CVE-2026-110264 reaches every GitLab version from 7.0 onward. A researcher using the handle joaxcar reported all four through GitLab's bug bounty program. As of October 23, none of the four was listed in CISA's Known Exploited Vulnerabilities catalog. Ruby has not requested CVE identifiers of its own for these fixes, "at least for now," it said, and told users to track the issues by GitLab's four CVE numbers instead. That leaves a gap for anyone who scans by CVE. GitLab's CVE records name only GitLab as the affected product, so a scanner that checks those records against installed Ruby versions has nothing to match. Ruby has treated this kind of bug as a vulnerability before, assigning CVE numbers to fixes in2022and2024, even though it has long been unsafe to build a regular expression from untrusted input. Itsdocumentationstill describes untrusted patterns only as a denial-of-service risk. Ruby said it will update its advisory if it requests any CVE identifiers. Self-managed GitLab instances need the release that fixes CVE-2026-110264. GitLabshipped iton October 21 and backported it as far as version 18.11.13. GitLab.com already runs the patched version, and GitLab Dedicated tenants on recent internal releases need no action, GitLab said. Because GitLab bundles its own copy of Ruby and patched it there, installing one of these fixed versions applies the fix. GitLab also publisheddetection rulesthat self-managed administrators can use to look for signs of exploitation attempts.

← VOLVER A CIBERSEGURIDAD