Se ha revelado una cadena de exploits en GitLab que demuestra cómo dos fallos de seguridad de memoria, previamente desconocidos en la biblioteca de análisis de JSON de Ruby llamada Oj, pueden combinarse para lograr la ejecución remota de código en instalaciones predeterminadas. Esta vulnerabilidad expone el código fuente, los secretos de Rails y los servicios internos. El hallazgo fue realizado por el investigador Yuhang Wu, de Depthfirst, como parte de la Open Defense Initiative.

Una cadena de exploits recién revelada en GitLab muestra cómo dos fallos de seguridad de memoria largamente ocultos en una biblioteca de análisis de JSON para Ruby, llamada Oj, podrían combinarse para lograr la ejecución remota de código en instalaciones predeterminadas de GitLab, exponiendo el código fuente, secretos de Rails y servicios internos.

Como parte de la Open Defense Initiative, el investigador de Depthfirst, Yuhang Wu, utilizó el sistema de análisis automatizado para escanear Oj, un analizador de JSON basado en C nativo de alto rendimiento ampliamente utilizado en aplicaciones Ruby, incluyendo GitLab.

El escaneo reveló 18 vulnerabilidades priorizadas, siete de las cuales eran errores de seguridad de memoria; dos de ellas habían persistido silenciosamente en Oj durante casi cinco años antes de ser convertidas en una cadena de exploits funcional.

Los dos fallos eran una escritura de pila de anidamiento no verificada en Oj::Parser.usual.parse y un estrechamiento inseguro de la longitud de la clave de 16 bits que filtraba un puntero de montón (heap pointer).

Individualmente, cada uno era limitado: uno ofrecía solo una primitiva de "escritura" repetida de un byte, y el otro revelaba una fracción de memoria fija de 29 bytes. Encadenados mediante una manipulación cuidadosa del asignador de montón, permitieron a los atacantes el control total de un puntero de devolución de llamada (callback pointer) y una forma de derrotar ASLR, permitiendo finalmente la ejecución de código arbitrario como el usuario del sistema "git".

Vulnerabilidades de GitLab permiten la ejecución de código

GitLab renderiza diffs legibles para humanos de archivos de Jupyter Notebook (.ipynb) utilizando una gema interna llamada ipynbdiff. Antes de generar este diff, la gema analiza cada revisión del cuaderno utilizando el analizador nativo de Oj para validar que el JSON contenga un campo "cells".

Debido a que un archivo de cuaderno es fundamentalmente un documento JSON, cualquier usuario autenticado que pudiera subir commits y ver un diff de commit podría introducir estructuras JSON maliciosas en esa llamada.

El exploit funcionaba subiendo dos archivos de cuaderno especialmente diseñados en una sola solicitud de commit-diff. La profundidad de anidamiento excesiva del primer archivo abusaba de la escritura de pila no verificada para redirigir un puntero de búfer interno, y posteriormente, las operaciones de montón hicieron que la memoria de un Array de Ruby se solapara con un puntero de devolución de llamada del analizador, permitiendo a los atacantes implantar una dirección elegida en p->start.

Una segunda filtración de puntero de montón, introducida dentro de una clave de objeto JSON excesivamente grande y renderizada en la salida HTML del diff, proporcionó a los atacantes la dirección necesaria para calcular la ubicación de memoria de bibliotecas centrales como libc y libruby, derrotando las protecciones ASLR.

Debido a que Puma (el servidor de aplicaciones Ruby de GitLab) ejecuta múltiples hilos que comparten una instancia de analizador nativo por trabajador, ambos archivos diseñados fueron procesados por el mismo analizador vulnerable dentro de una sola solicitud, permitiendo que el segundo archivo activara la devolución de llamada corrupta y ejecutara un comando de shell a través de system().

A diferencia de problemas anteriores de ejecución remota de código en GitLab que dependían de la falsificación de solicitudes del lado del servidor (SSRF) contra instancias internas de Redis, esta cadena evitó completamente las defensas SSRF modernas de GitLab al atacar una dependencia nativa no segura en memoria embebida dentro de código Ruby que, de otro modo, sería seguro.

Cualquier miembro del proyecto con acceso ordinario de subida y vista de diff podría activar la cadena sin derechos de administrador, acceso a CI/CD, ni interacción de la víctima, lo que lo hace especialmente peligroso para instancias de GitLab autogestionadas compartidas o multi-inquilino.

La explotación exitosa permitió ejecutar comandos como la cuenta "git" que impulsa los trabajadores de Puma de GitLab. Esto podría exponer potencialmente el código fuente del repositorio, los secretos de la aplicación Rails, credenciales de servicio y cualquier servicio interno accesible desde el host de GitLab. Como resultado, existe un riesgo de robo de datos, manipulación de código y movimiento lateral, según Depthfirst en una declaración.

Versiones afectadas y correcciones

Componente	Versiones Afectadas	Primera Versión Corregida
GitLab CE/EE	15.2.0–18.10.7	18.10.8
GitLab CE/EE	18.11.0–18.11.4	18.11.5
GitLab CE/EE	19.0.0–19.0.1	19.0.2
Gema Oj	3.13.0–3.17.1	3.17.3

GitLab.com ya estaba parcheado al momento de la revelación, y los clientes de Dedicated no requirieron ninguna acción, pero los operadores autogestionados en los rangos de versiones afectados deben actualizar inmediatamente.

El código vulnerable del analizador Oj se fusionó en agosto de 2021, y GitLab comenzó a utilizar la llamada de análisis afectada en julio de 2022 a través de GitLab 15.2.0.

El investigador informó los errores centrales de Oj el 21 de mayo de 2026; Oj fusionó las correcciones el 27 de mayo, después de que los fallos persistieran durante 1,753 días, publicándose Oj 3.17.3 el 4 de junio. La cadena específica de GitLab se informó el 5 de junio, se confirmó el 8 de junio y se parcheó el 10 de junio de 2026, en las versiones 19.0.2, 18.11.5 y 18.10.8.

El mismo esfuerzo de investigación produjo nueve CVE publicados para Oj además de los dos utilizados en esta cadena, abarcando desbordamientos de búfer de pila y montón, múltiples condiciones de uso posterior a la liberación (use-after-free) en devoluciones de llamada SAJ e iteradores de documentos, un memcpy de tamaño negativo y un desbordamiento de entero en archivos grandes, subrayando cuán profundamente puede esconderse el riesgo de corrupción de memoria dentro de extensiones nativas empaquetadas con aplicaciones Ruby supuestamente "seguras".

Los equipos de seguridad que ejecutan GitLab autogestionado deben priorizar el parcheo a las versiones corregidas mencionadas arriba y auditar los árboles de dependencias de Ruby en busca de extensiones nativas de C, ya que el código no seguro en memoria dentro de una gema confiable puede socavar las garantías de seguridad de memoria de todo un stack de aplicaciones Ruby.

Fuentes:
https://cybersecuritynews.com/gitlab-vulnerabilities-enable-code-execution/