GitLab CVE-2026-97229: Rapid7 reproduce la RCE; usa la 19.3.5

📌 Novedades posteriores: GitLab CVE-2026-110264: también inyección LDAP y request smuggling (22 de octubre de 2026) · GitLab 19.5.1: nueva RCE sin autenticación, CVE-2026-110264 (22 de octubre de 2026)

El 12 de octubre ARX News trató la CVE-2026-97229 (CVSS 10.0) de GitLab Community Edition (CE) y Enterprise Edition (EE), el desbordamiento de enteros en el compilador de expresiones regulares de CI/CD, a partir de los avisos del CERT-EU y del CERT-FR. En las horas siguientes llegaron el boletín de GitLab recogido por la prensa, los avisos de INCIBE-CERT, del CERT.LV y del CCB belga y, sobre todo, un primer análisis de Rapid7. A continuación, las novedades que cambian las prioridades.

En la rama 19.3 la versión corregida es la 19.3.5

El punto más práctico afecta a la rama 19.3. El boletín de GitLab, titulado según INCIBE-CERT «GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8», indica como versión corregida la 19.3.5. El mismo número aparece en Help Net Security, CSO Online, Security Affairs y en el aviso del CERT.LV. El CERT-EU, el CERT-FR y BleepingComputer indicaban en cambio la 19.3.4, y es el número de nuestro primer artículo.

Las fuentes no explican la diferencia. Por prudencia, en la rama 19.3 considera corregida solo la 19.3.5 o una versión posterior, aunque ya hayas instalado la 19.3.4.

Versiones afectadas según GitLab, tal como las recogen la prensa e INCIBE-CERT:

• desde la 19.2 hasta la 19.2.8, sin incluirla;
• desde la 19.3 hasta la 19.3.5, sin incluirla;
• desde la 19.4 hasta la 19.4.2, sin incluirla.

GitLab.com ya utiliza la versión corregida y los clientes de GitLab Dedicated no tienen que hacer nada. Según CSO Online, GitLab precisa que, cuando no se indica un tipo de instalación (omnibus, desde el código fuente, chart de Helm), están afectados todos.

Qué ha comprobado Rapid7

Según la actualización de Help Net Security del 13 de octubre, la única fuente que lo recoge, los investigadores de Rapid7 han reproducido la ejecución de código en la imagen oficial de GitLab CE 19.4.1 sin actualizar; la misma entrada no funcionó en la imagen 19.4.2.

Rapid7 aclara también las condiciones de explotación. El vector CVSS del fabricante indica ataque por red, baja complejidad, sin privilegios y sin interacción del usuario. Para Rapid7, sin embargo, el atacante primero debe poder hacer commit, en una rama de un proyecto público, de un archivo .gitlab-ci.yml malicioso y de una ruta del repositorio con caracteres UTF-8. En las instancias self-managed que permiten a los usuarios crear proyectos públicos basta con una cuenta normal.

La exposición depende, por tanto, de quién puede obtener una cuenta en la instancia y crear proyectos públicos. En términos de MITRE ATT&CK sigue siendo la explotación de una aplicación expuesta (T1190), pero con una cuenta válida.

Según Rapid7, por ahora no hay una explotación confirmada en ataques reales; INCIBE-CERT también indica la vulnerabilidad como no explotada. Aun así, Rapid7 recomienda actualizar con urgencia, fuera del ciclo normal de parches. El CCB belga y el CERT.LV piden actualizar de inmediato.

La vulnerabilidad la notificó a través del programa de bug bounty de GitLab en HackerOne el investigador «joaxcar» (Johan Carlsson, según CSO Online). Según Help Net Security, el mismo investigador notificó también la CVE-2026-7767, un open redirect de severidad media en el proxy de Kubernetes de GitLab que puede hacer llegar tokens de autenticación a un servidor no previsto.

Las demás correcciones de la versión

Según INCIBE-CERT, las 24 vulnerabilidades corregidas se reparten así: 1 crítica, 5 altas, 14 medias y 4 bajas. Respecto a nuestro primer artículo, CSO Online asocia un identificador a las cinco de severidad alta:

• CVE-2026-92883 (CVSS 8.7): cross-site scripting en la salida con resaltado de sintaxis, por una sanitización insuficiente de los atributos HTML;
• CVE-2026-16301 (CVSS 8.5): un usuario con rol Developer puede ejecutar pipelines en ramas protegidas sin autorización;
• CVE-2026-14814 (CVSS 8.2): es el cache poisoning ya citado; afecta a las respuestas de los archivos raw del repositorio y puede hacer que las pipelines atacadas ejecuten contenido malicioso, con acceso a las variables de entorno protegidas;
• CVE-2026-81839 (CVSS 7.7): un usuario autenticado puede ejecutar pipelines arbitrarias en un proyecto transferido, con los privilegios del nuevo grupo;
• CVE-2026-96893 (CVSS 7.3): en GitLab Duo, un usuario autenticado puede insertar contenido manipulado en las instrucciones de los agentes de IA, con posible ejecución de comandos no deseados atribuida a otros usuarios.

Las vulnerabilidades de severidad media y baja afectan a GitLab Pages, al proxy de Kubernetes, a las API GraphQL, a las merge requests, a los roles personalizados, al package registry y a la importación de repositorios y proyectos. Según CSO Online, GitLab publicará los detalles de las incidencias 90 días después de la versión: no conviene esperarlos para actualizar.

Impacto para las empresas europeas e italianas

Las condiciones que describe Rapid7 dejan más expuestas las instancias de GitLab compartidas con muchos usuarios, incluidos proveedores, consultores y colaboradores externos, sobre todo si permiten crear proyectos públicos. Suelen ser las mismas instancias que guardan las pipelines de despliegue y los secretos.

Los avisos de los CSIRT nacionales de Bélgica, España y Letonia, además de los del CERT-EU y del CERT-FR, confirman la atención en Europa. Para las entidades sujetas a NIS2 vale lo que ya escribimos en el primer artículo: gestión de vulnerabilidades, seguridad de la cadena de suministro del software y, en caso de incidente significativo, notificación al CSIRT nacional, que en Italia es el CSIRT Italia de la ACN.

Qué hacer ahora

1. Rama 19.3: actualiza a la 19.3.5 o posterior, aunque ya estés en la 19.3.4. En las demás ramas: 19.4.2 o 19.2.8 o posteriores. Para la rama 19.1 sigue valiendo lo que ya escribimos: no se indica ninguna corrección, pasa al menos a la 19.2.8.
2. Prioridades: empieza por las instancias accesibles desde Internet y por aquellas con registro abierto o en las que los usuarios pueden crear proyectos públicos.
3. Revisa la configuración: comprueba quién puede registrarse y quién puede crear proyectos públicos, la condición indicada por Rapid7. No es una mitigación indicada por GitLab: la única corrección es la actualización.
4. Revisa los repositorios: busca cambios recientes en .gitlab-ci.yml en proyectos públicos, sobre todo de cuentas nuevas o poco usadas, y rutas del repositorio con caracteres no ASCII. Ninguna fuente ha publicado indicadores de compromiso.
5. Si encuentras actividad sospechosa: considera expuesto el servidor, sustituye los secretos que usan las pipelines y valora las obligaciones de notificación.

Cómo ayuda ARXDOME

ARX Expose identifica los servicios que tu empresa expone en Internet y los productos con vulnerabilidades conocidas: te ayuda a saber si una instancia de GitLab es accesible desde fuera. ARX Shield enumera las vulnerabilidades abiertas en las máquinas supervisadas. ARX Sentry recoge registros y eventos de los servidores en los que está instalado el agente y controla la integridad de los archivos en las carpetas establecidas. Con ARX Horizon consultas desde el portal los detalles de las vulnerabilidades.

Última actualización: 13 de octubre de 2026