GitLab corrige una vulnerabilidad crítica de ejecución remota de código que afecta a todas las versiones desde 2014

GitLab lanzó actualizaciones de seguridad de emergencia el 21 de octubre para abordar una vulnerabilidad crítica que permite a los atacantes ejecutar código arbitrario en servidores autoalojados sin necesidad de autenticación. El fallo, identificado como CVE-2026-110264, tiene una puntuación perfecta de 10.0 en el Sistema Común de Puntuación de Vulnerabilidades (CVSS) y afecta a todas las versiones del software desde la 7.0, lanzada en 2014.

Este parche es urgente incluso para los administradores que aplicaron la actualización de seguridad anterior el 12 de octubre. Aquella corrección inicial solo cubría las versiones 19.2 y posteriores, dejando expuestas las instalaciones más antiguas, mientras que las nuevas versiones corregidas se sitúan apenas un nivel de parche por encima de esos lanzamientos recientes. En consecuencia, muchos sistemas considerados seguros siguen siendo vulnerables hasta que se aplique esta última ronda de actualizaciones.

Qué ocurrió

La vulnerabilidad se origina en un desbordamiento de entero dentro de Onigmo, el motor de expresiones regulares integrado en Ruby que GitLab incluye y parchea dentro de sus propias distribuciones. Cuando el compilador procesa una expresión regular especialmente diseñada, puede provocar este desbordamiento, lo que potencialmente permitiría a un usuario no autenticado ejecutar código en el servidor anfitrión. GitLab no ha revelado las condiciones específicas necesarias para explotar el fallo, lo que significa que los administradores no pueden confiar en cambios de configuración para mitigar el riesgo.

GitLab abordó el problema publicando versiones corregidas simultáneamente en siete ramas de lanzamiento diferentes. Este amplio alcance incluye cuatro versiones más antiguas que la política estándar de soporte de GitLab, que normalmente solo cubre la versión actual y las dos mensuales anteriores. La empresa declaró que reservó este esfuerzo excepcional de portación hacia atrás (backporting) para problemas graves, reconociendo la naturaleza generalizada de la debilidad subyacente del motor.

Aunque GitLab informa que no hay evidencia de que este fallo específico haya sido explotado en entornos reales, y aún no aparece en el catálogo de vulnerabilidades conocidas explotadas de la CISA de EE. UU., el perfil de riesgo es extremo. El mismo investigador, conocido con el alias joaxcar, ha reportado otros tres fallos de ejecución de código en el mismo motor de expresiones regulares durante el último mes. A diferencia de esos problemas anteriores, que estaban limitados a versiones más recientes o requerían acceso autenticado, esta vulnerabilidad abarca más de una década de historia del software y no requiere inicio de sesión.

Detalles clave

• ID de la vulnerabilidad: CVE-2026-110264, calificada con 10.0 (Crítica) en la escala CVSS.
• Versiones afectadas: Todas las instancias de GitLab autoalojadas desde la versión 7.0 (2014) hasta las últimas versiones previas al parche.
• Causa raíz: Desbordamiento de entero en el compilador de expresiones regulares Onigmo durante el procesamiento de expresiones manipuladas.
• Vector de ataque: Ejecución remota de código sin autenticación; no se requiere inicio de sesión ni interacción del usuario.
• Disponibilidad del parche: Parches publicados para las versiones 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13.
• Detección: GitLab proporcionó dos reglas de detección en formato Sigma, "Onigmo native worker crash" y "Org mode render error burst", para monitorear los registros de la aplicación.

Contexto

Las expresiones regulares son patrones utilizados para hacer coincidir combinaciones de caracteres en cadenas de texto, ampliamente usados en programación para validación de datos y funciones de búsqueda. El motor que procesa estos patrones, en este caso Onigmo, debe manejar entradas complejas de manera eficiente. Un desbordamiento de entero ocurre cuando un cálculo produce un número mayor que el espacio de almacenamiento asignado para él, haciendo que el valor dé la vuelta a un número negativo o a un pequeño número positivo. En contextos de seguridad, esto puede corromper estructuras de memoria, permitiendo a los atacantes inyectar y ejecutar código malicioso.

GitLab incluye su propia versión del intérprete de Ruby y sus bibliotecas asociadas, incluyendo Onigmo. Dado que este motor está embebido en cada versión de GitLab desde la 7.0, la vulnerabilidad es omnipresente en toda la base instalada de instancias autoalojadas. Los usuarios alojados en la nube en GitLab.com no se ven afectados, ya que el proveedor gestiona la infraestructura subyacente y ya ha desplegado la corrección.

Por qué importa

Para los equipos que ejecutan instancias de GitLab autoalojadas, este incidente destaca los riesgos ocultos de las dependencias de software a largo plazo. Incluso si una organización mantiene un riguroso calendario de parcheo para las versiones recientes, la profundidad de esta vulnerabilidad significa que las instancias heredadas o aquellas en rutas de soporte extendido están críticamente expuestas. El hecho de que el parche del 12 de octubre no cubriera las versiones más antiguas crea una brecha peligrosa donde los administradores podrían creer que están protegidos cuando no lo están.

El impacto operativo de aplicar este parche no es trivial. Las actualizaciones a las versiones 19.4.3 y 19.3.6 incluyen cambios en el esquema de la base de datos que requieren tiempo de inactividad en servidores de nodo único. Para entornos de alta disponibilidad, esto exige una planificación cuidadosa utilizando los procedimientos de actualización sin tiempo de inactividad de GitLab para configuraciones multinodo. Los equipos deben equilibrar la amenaza de seguridad inmediata frente a la posible interrupción del servicio causada por el proceso de parcheo.

Además, la falta de una solución alternativa significa que no existe una medida provisional. Los administradores no pueden simplemente deshabilitar una función o ajustar una configuración para bloquear el vector de ataque. La única protección definitiva es actualizar a una de las versiones parcheadas. Esto ejerce presión sobre los equipos de DevOps para priorizar esta tarea de mantenimiento por encima de otros elementos de la hoja de ruta, lo que podría retrasar el desarrollo de funciones u otras mejoras de infraestructura.

Qué puedes hacer

• Identifica tu versión actual de GitLab y compárala con la tabla de versiones corregidas para determinar la ruta de actualización necesaria.
• Programa una ventana de mantenimiento inmediata para instancias de nodo único, teniendo en cuenta el posible tiempo de inactividad debido a migraciones de base de datos.
• Implementa las reglas de detección Sigma proporcionadas en tu sistema de gestión de registros para monitorear eventos de "Onigmo native worker crash" o "Org mode render error burst".
• Verifica que los clústeres multinodo estén configurados para actualizaciones sin tiempo de inactividad antes de iniciar el proceso de parcheo para evitar interrupciones del servicio.
• Revisa los registros de acceso en busca de actividad inusual antes de aplicar el parche, aunque ten en cuenta que la explotación puede dejar rastros mínimos sin las reglas de detección específicas.
• Comunica la urgencia a las partes interesadas, enfatizando que este parche aborda un fallo presente en todas las versiones desde 2014, no solo en los lanzamientos recientes.