GitLab parchea un fallo CVSS 10 de ejecución remota de código en CI/CD

GitLab ha publicado el 12 de octubre de 2026 los parches del CVE-2026-97229, un desbordamiento de entero en el compilador de expresiones regulares de CI/CD que, con una puntuación CVSS de 10,0, permite ejecutar código en el servidor de las instalaciones autoalojadas. Rapid7 ha reproducido la ejecución de comandos en una imagen oficial sin parchear y ha enlazado una prueba de concepto el 13 de octubre, aunque ninguna de las fuentes consultadas confirma explotación activa.

Qué ha pasado

GitLab lanzó el 12 de octubre de 2026 las versiones 19.4.2, 19.3.5 y 19.2.8 de Community Edition (CE) y Enterprise Edition (EE). En su aviso de seguridad describe el fallo como un problema que podía permitir a un usuario sin autenticar «execute arbitrary code on the GitLab server via a specially crafted regular expression» (ejecutar código arbitrario en el servidor de GitLab mediante una expresión regular manipulada), incluida en una configuración de CI/CD. La causa, recoge Help Net Security, es una validación insuficiente de esa expresión regular.

El fallo lo notificó el investigador que firma como joaxcar a través del programa de recompensas de GitLab en HackerOne. La misma versión corrige otras 23 vulnerabilidades, hasta un total de 24, y INCIBE-CERT la recogió en su aviso del 13 de octubre de 2026. GitLab.com ya ejecuta la versión parcheada y los clientes de GitLab Dedicated no tienen que hacer nada, de modo que el riesgo recae en quien gestiona su propia instancia.

La calificación de «sin autenticar» admite matices. Rapid7 sostiene que el vector del fabricante está incompleto porque «an attacker must have a mechanism to plant a malicious CI/CD configuration» (el atacante necesita un mecanismo para colocar una configuración de CI/CD maliciosa). En la práctica, eso exige poder escribir en un proyecto público, algo que cualquier cuenta ordinaria puede hacer si la instancia permite crear proyectos públicos.

Detalles técnicos

Rapid7 ha explicado el mecanismo. La expresión regular manipulada se compila primero como US-ASCII y supera la validación de GitLab. Cuando se evalúa contra una ruta de repositorio con caracteres UTF-8, la biblioteca Onigmo la recompila una vez terminada esa validación. Un desbordamiento de entero en el cálculo del tamaño del programa genera instrucciones de regex inválidas, el flujo de control deja de estar protegido y el resultado es un comando del sistema ejecutado como el usuario git. El diagrama siguiente resume la cadena a partir de la descripción de Rapid7. No es un esquema del propio fabricante.

Rapid7 validó la ejecución en la imagen oficial de GitLab 19.4.1 CE para Linux amd64 con ASLR activado y comprobó que la misma entrada no funciona contra la imagen parcheada 19.4.2. Su repositorio de PoC advierte de que el objetivo debe coincidir con la disposición de Ruby de esa versión y de que la prueba necesitó unos 9 GiB de memoria libre. El README añade que la petición HTTP suele acabar en un error 502 y que el éxito se juzga por la salida del comando. Esos requisitos frenan el uso indiscriminado del código, pero no lo hacen inviable para un atacante que prepare su entorno. Rapid7 anuncia un análisis técnico propio con la causa raíz y la cadena completa.

El parche cierra otras cinco vulnerabilidades de gravedad alta. Todas figuran en el aviso de GitLab, que además detalla 14 de gravedad media y 4 de gravedad baja, como muestra el gráfico.

Dos de las altas afectan directamente a los secretos de CI/CD. El CVE-2026-16301 deja a un usuario con rol Developer ejecutar pipelines en ramas protegidas sin autorización, y el CVE-2026-14814 permite envenenar respuestas en caché de ficheros sin procesar del repositorio, con el riesgo de que un pipeline ajeno ejecute contenido malicioso y acceda a variables de entorno protegidas, según el aviso de GitLab.

A quién afecta

Afecta a toda instancia autoalojada de GitLab CE o EE en las ramas 19.2, 19.3 y 19.4 anteriores a las versiones corregidas, con independencia del tipo de despliegue. Las fuentes discrepan en un detalle. Algunos medios dieron la 19.3.4 como versión corregida, pero GitLab recomienda la 19.3.5 porque la 19.3.4 tenía un fallo en las páginas de merge request con la integración Ona activada. Conviene fiarse del aviso del fabricante.

El riesgo es mayor en instancias que admiten registro abierto o que dejan a usuarios poco fiables crear proyectos públicos, porque ahí la condición previa que señala Rapid7 se cumple sin esfuerzo. Un servidor GitLab concentra código fuente, variables de CI/CD, tokens de acceso y conexiones con runners y entornos cloud. SOCRadar apunta que una ejecución de código en ese servidor podría exponer todo eso y extenderse a los sistemas de despliegue conectados.

Ninguna fuente consultada ofrece cifras de exposición en España. INCIBE-CERT sí incluye el producto en su sistema de alerta temprana, lo que sitúa a GitLab entre las plataformas que el organismo vigila para empresas y ciudadanos.

Qué hacer

1. Comprueba la versión de cada instancia autoalojada con los comandos de abajo y actualiza a la 19.4.2, la 19.3.5 o la 19.2.8, o a una posterior. Salta la 19.3.4.
2. Planifica la ventana de mantenimiento. El parche incluye migraciones de base de datos, así que una instancia de un solo nodo tendrá parada hasta que terminen, mientras que una instalación multinodo puede actualizarse sin parada con los procedimientos de GitLab. Actualiza los GitLab Runner por separado.
3. Si no puedes actualizar hoy, aplica las medidas provisionales de Rapid7. Restringe el acceso anónimo a los proyectos públicos y evita que usuarios no fiables creen proyectos públicos o escriban en ellos. Estas medidas solo bloquean la vía de entrega demostrada y no corrigen el compilador, y GitLab no ha publicado ningún workaround.
4. Revisa si tu instancia permite el autorregistro de usuarios y qué cuentas se han creado desde el 12 de octubre de 2026. Busca también ficheros .gitlab-ci.yml nuevos en proyectos públicos con rutas de repositorio que contengan caracteres UTF-8 inusuales.
5. Busca señales de ejecución en el servidor. GitLab no ha publicado IoC, de modo que SOCRadar propone hipótesis de búsqueda, no indicadores confirmados. Mira procesos hijos inesperados de los servicios de GitLab, usuarios, tokens, deploy keys, runners o hooks nuevos, cambios no previstos en pipelines o repositorios y conexiones salientes anómalas desde el servidor.
6. Si encuentras ejecución sospechosa, conserva los logs y rota las variables de CI/CD, los tokens, las claves de despliegue y las credenciales cloud accesibles desde GitLab. Una buena gestión de identidades y accesos en la nube limita el daño de cada secreto robado.
7. Aplica en la misma ventana el resto de correcciones, en especial las de los CVE-2026-16301 y CVE-2026-14814, que tocan los pipelines y las variables protegidas.
8. Notifica el incidente a INCIBE-CERT si eres empresa o ciudadano, o al CCN-CERT si perteneces al sector público.

# Instalación Omnibus
sudo gitlab-rake gitlab:env:info

# Contenedor Docker (sustituye "gitlab" por el nombre de tu contenedor)
docker exec -it gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# Últimas cuentas creadas en la instancia
sudo gitlab-rails runner 'User.order(created_at: :desc).limit(20).each { |u| puts [u.username, u.created_at, u.state].join(" ") }'

Comandos habituales de administración de GitLab, redactados por ciberseguridad.blog. No proceden de las fuentes citadas.

Análisis

Es el tercer fallo crítico de GitLab en dos meses. El de septiembre, el CVE-2026-85706, también con CVSS 10,0, se corrigió en las versiones 19.3.2, 19.2.6 y 19.1.8, y según The Hacker News watchTowr detectó sondeos desde las 06:00 UTC del 11 de septiembre de 2026. CISA lo añadió ese mismo día a su catálogo KEV con fecha límite del 14 de septiembre. Aquel precedente invita a no esperar a que aparezca un exploit en circulación para parchear, y esta vez ya hay una PoC pública antes de que nadie haya reportado ataques.

Lo que no dice el aviso oficial es cuánto depende la explotación de la configuración de cada instancia. Rapid7 lo deja claro: el 10,0 describe el peor caso, el de un servidor con registro abierto y proyectos públicos. Una instancia interna sin registro de usuarios externos tiene una exposición menor, pero la puntuación no refleja que cualquier empleado con permiso de escritura en un proyecto público también cumple la condición. Nuestra lectura es que ninguna instancia con CI/CD debería quedarse sin parchear esperando a medir ese matiz.

La semana ya trae precedentes de equipos perimetrales y de acceso que cayeron con rapidez, como el aviso del FBI sobre FortiBleed o la cadena de zero-days en Ivanti Connect Secure. GitLab no es un equipo de borde, pero hospeda las claves del software que una organización despliega, y por eso compensa tratarlo con la misma urgencia. Si ejecutas runners sobre contenedores, repasa además la seguridad de Kubernetes y las pautas de detección de una APT para cubrir un posible movimiento lateral. Para ampliar el contexto sobre cómo proteger las interfaces que exponen estos servicios, consulta nuestra guía sobre la seguridad de las APIs.