Prueba de concepto pública expone RCE silencioso en GitLab: falla sin CVE deja servidores corporativos descubiertos
Investigadores de depthfirst publicaron el 25 de julio código de explotación funcional para RCE en GitLab, corregido seis semanas antes sin CVE y sin aviso de seguridad. Cualquier usuario con acceso de push puede comprometer el servidor.
El exploit y lo que hace
Investigadores de depthfirst publicaron el 25 de julio de 2026 código de explotación funcional para una vulnerabilidad de ejecución remota de código en GitLab. El exploit ejecuta comandos como el usuario git en cualquier servidor autogestionado en la versión 18.11.3 que no haya aplicado el parche del 10 de junio. No requiere derechos de administrador, acceso a pipelines de CI/CD, permisos de runner ni interacción de un mantenedor: cualquier usuario autenticado con permiso de push para un único proyecto, el nivel de acceso que cualquier desarrollador en un repositorio abierto ya posee por defecto, tiene lo suficiente para desencadenar la cadena completa.
El atacante realiza el commit de un Jupyter notebook especialmente construido y abre el diff de revisión en GitLab, operación que filtra un puntero de heap del servidor. Repeticiones controladas permiten que una sonda automatizada mapee las bibliotecas cargadas en memoria. Dos notebooks adicionales desencadenan la carga útil. La técnica no depende de fallas en el kernel ni en el sistema operativo host, sino del comportamiento predecible de la biblioteca Oj al procesar el diff de contenidos JSON anidados específicos. La ausencia de interacción del lado de la víctima, sin hacer clic en un enlace, aprobar un merge request o abrir un archivo, es el atributo que eleva el riesgo en ambientes corporativos con muchos colaboradores externos.
Por qué no hay CVE y lo que eso significa
GitLab corrigió la biblioteca Oj a la versión 3.17.3 en el lanzamiento del 10 de junio, pero registró el cambio como corrección de bug común, no como actualización de seguridad. Ningún CVE fue emitido. La actualización no constó en la tabla de correcciones de seguridad de las versiones 18.11.4 y 18.11.5. El resultado práctico: equipos de gestión de parches que dependen exclusivamente de alertas con CVSS score tuvieron 45 días para aplicar una corrección que no señalizaba urgencia, mientras depthfirst preparaba el proof-of-concept funcional.
La empresa optó por publicar el exploit sin coordinación previa con el proveedor. La justificación es clara: el parche estaba disponible desde hace seis semanas y la ventana de remediación razonable había expirado sin que GitLab clasificara el riesgo públicamente. GitLab no había emitido una nota de seguridad específica sobre el exploit de depthfirst hasta el cierre de este artículo, lo que también significa que los escáneres de vulnerabilidades basados en CVE no identifican el servidor desactualizado como vulnerable.
Dimensión del riesgo global
Más de 40 mil servidores GitLab autogestionados están accesibles directamente en internet, según una investigación de Cycode con datos de Shodan. Este número representa solo las instancias expuestas públicamente; el universo de servidores protegidos por VPN, redes internas y proxies reversos es considerablemente mayor. El modelo autogestionado es predominante en sectores regulados, como financiero, salud y defensa, donde políticas internas prohíben el uso de instancias SaaS. Estos ambientes tienden a tener ciclos de parches medidos en semanas, atados a ventanas de mantenimiento mensuales, no en horas.
El riesgo no se restringe a organizaciones estadounidenses. Consultoras de TI en India, Alemania y Brasil frecuentemente hospedan instancias autogestionadas para proyectos de clientes, a menudo en ambientes de desarrollo compartido. Un servidor comprometido en este modelo puede exponer simultáneamente código fuente, variables de entorno y tokens de CI/CD de múltiples proyectos y múltiples clientes. El bajo umbral de acceso, permiso de push para cualquier repositorio de la instancia, amplía significativamente la superficie de ataque en organizaciones con cientos de colaboradores externos.
Qué hacer ahora
La corrección existe y es objetiva: actualizar a 18.10.8, 18.11.5 o 19.0.2. Las tres versiones incluyen la corrección de la biblioteca Oj 3.17.3. Los ambientes protegidos por proxy reverso, VPN o Web Application Firewall continúan vulnerables si un atacante dispone de credenciales válidas de cualquier usuario con permiso de push, ya sea por phishing o por credential stuffing sobre repositorios con contribuciones externas.
La ausencia de CVE no puede servir de justificación para postergar el parche. El exploit de depthfirst es público desde el 25 de julio y funciona contra cualquier instancia desactualizada. La ventana entre la publicación de un PoC y el inicio de explotación activa por actores menos sofisticados suele medirse en días, no semanas. Equipos con ciclos de mantenimiento mensuales o trimestrales deben evaluar el parcheo de emergencia fuera del calendario estándar.