Alerta GitLab: exploit público para vulnerabilidad crítica RCE, la corrección estaba oculta en un error común

Introducción

El 24 de julio de 2026 el equipo de investigación depthfirst publicó un exploit completo para una vulnerabilidad crítica de ejecución remota de código (RCE) que afecta a GitLab Community Edition (CE) y Enterprise Edition (EE) auto-hospedadas. La falla permite que un usuario autenticado con permisos de push obtenga una shell en el servidor con los privilegios del proceso git, simplemente cargando un notebook Jupyter malicioso. La particularidad más alarmante es que GitLab ya había distribuido una corrección el 10 de junio pasado, pero la había clasificado como un simple “bug fix” ordinario, omitiéndola de la tabla de actualizaciones de seguridad. Como resultado, muchos administradores podrían no haber aplicado el parche, dejando expuestas miles de instancias a un ataque ahora facilitado por la disponibilidad pública del código ofensivo.

Análisis técnico

La vulnerabilidad reside en dos errores distintos de corrupción de memoria en el parser JSON nativo Oj (Optimized JSON), una gema Ruby ampliamente utilizada. Las versiones de Oj anteriores a la 3.17.3 no manejan correctamente ciertas estructuras JSON complejas, provocando desbordamientos y lecturas fuera de límites. En GitLab, el componente ipynbdiff – encargado de mostrar las diferencias entre versiones de notebooks Jupyter (archivos .ipynb) – utiliza internamente Oj::Parser.usual.parse para procesar el contenido de los archivos. Un atacante con acceso de escritura a un repositorio puede crear un notebook especialmente manipulado y subirlo mediante push. Cuando cualquier usuario (incluido el atacante) visualiza el diff del notebook en la interfaz web, el parser vulnerable se ejecuta y el payload contenido en el archivo toma el control.

El exploit liberado por depthfirst opera en dos fases:

1. Fuga de memoria: explotando el primer error, el payload fuerza al parser a revelar direcciones de memoria, evadiendo ASLR (Address Space Layout Randomization).
2. Ejecución arbitraria: mediante heap-spray, se inyecta shellcode que modifica el flujo de ejecución del proceso Puma (el servidor de aplicaciones de GitLab) para ejecutar comandos elegidos por el atacante.

El exploit está optimizado para GitLab 18.11.3 en arquitectura x86-64. En instalaciones recientes el proceso requiere algunos minutos, mientras que en servidores con mucho tiempo de actividad puede llevar horas debido a la fragmentación de la memoria heap. La adaptación a otras builds x86-64 es relativamente sencilla (solo requiere actualizar los offsets y gadgets ROP), mientras que el port a ARM64 implica una reescritura significativa.

Las versiones de GitLab vulnerables son:

• de la 15.2.0 a la 18.10.7
• de la 18.11.0 a la 18.11.4
• de la 19.0.0 a la 19.0.1

Las correcciones se introdujeron con el lanzamiento de Oj 3.17.3 (4 de junio de 2026) e integradas en las posteriores versiones de GitLab: 18.10.8, 18.11.5 y 19.0.2. Dentro de GitLab también se modificó ipynbdiff para usar parsers más robustos, eliminando la vía de ataque.

Impacto

Obtener una shell como usuario git en el servidor GitLab significa comprometer prácticamente toda la plataforma. El atacante puede:

• Leer y alterar todo el código fuente alojado.
• Acceder a los secretos Rails (claves de cifrado, tokens de sesión) y a las credenciales de servicio (base de datos, integraciones externas).
• Recopilar variables de entorno CI/CD, tokens de acceso y potencialmente moverse lateralmente hacia otros servicios accesibles desde el host.
• Modificar pipelines CI/CD para distribuir payloads maliciosos o exfiltrar datos a gran escala.

Aunque el proceso atacado está confinado al usuario git, el alcance del daño depende del aislamiento del contenedor o de la máquina virtual en la que se ejecuta GitLab. Las instancias que funcionan con versiones sin mantenimiento (de la 15.2 a la 18.9) no reciben backports: permanecen vulnerables sin corrección oficial, a menos que se realice una migración forzada a una versión soportada. Hasta el 24 de julio no se registraban ataques activos en la naturaleza (in-the-wild), pero la publicación del exploit cambia radicalmente el panorama de amenazas.

Mitigación

La prioridad absoluta es aplicar inmediatamente la actualización a una de las versiones que contienen la corrección:

• GitLab 18.10.8
• GitLab 18.11.5
• GitLab 19.0.2 (o posteriores)

Los administradores que confían únicamente en la tabla resumen de “correcciones de seguridad” en las notas de la versión podrían no haber instalado el parche del 10 de junio, ya que GitLab lo etiquetó como “corrección de error”. Por lo tanto, se recomienda verificar manualmente la versión en uso, especialmente en entornos con políticas de actualización selectivas.

Para despliegues con Helm u Operator en Kubernetes, es fundamental comprobar la versión de la imagen del servicio Webservice (que ejecuta Puma) y no la del chart o del Operator, ya que esta última podría enmascarar un componente obsoleto.

No existe un workaround oficial ni validado para quienes no pueden actualizar de inmediato. Limitar el acceso a los repositorios y a la renderización de los diffs de notebook solo a usuarios estrictamente de confianza reduce la superficie de ataque, pero GitLab no ofrece una opción documentada para deshabilitar completamente la vía vulnerable. Para indicaciones específicas, se recomienda contactar al soporte de GitLab.

FAQ

1. ¿Qué versiones exactas de GitLab están afectadas?
Son vulnerables todas las versiones autogestionadas desde la 15.2.0 hasta la 18.10.7, de la 18.11.0 a la 18.11.4 y de la 19.0.0 a la 19.0.1. Las versiones anteriores a la 15.2.0 utilizan parsers diferentes y no están expuestas. Las versiones 18.10.8, 18.11.5, 19.0.2 y posteriores contienen la corrección.

2. ¿Cómo puedo verificar si mi instancia ya ha sido comprometida?
Por el momento no se han difundido indicadores de compromiso (IoC) públicos. Sin embargo, dada la naturaleza del ataque (ejecución de comandos arbitrarios como git), se recomienda monitorizar los logs del sistema en busca de procesos inusuales, conexiones de red salientes anómalas o modificaciones inesperadas en los archivos de configuración de GitLab. La ausencia de señales no garantiza que el sistema esté limpio: la actualización oportuna sigue siendo la contramedida esencial.

3. ¿Por qué GitLab no emitió un aviso de seguridad con un CVE?
En el momento de la publicación del exploit, GitLab aún no había comentado la decisión de clasificar la corrección como “bug ordinario”. Normalmente vulnerabilidades de esta gravedad reciben un identificador CVE y se enumeran en la sección de seguridad de las notas de la versión. La falta de transparencia probablemente extendió el período de exposición para muchos administradores. Se esperan más comunicaciones oficiales.