GitLab CE/EE: CVE-2026-97229 crítica y ya explotada

GitLab CE/EE: CVE-2026-97229 crítica y ya explotada

Qué es y a quién afectaLa CVE-2026-97229 es una vulnerabilidad de desbordamiento de entero (tipo CWE-190) en GitLab Community Edition y Enterprise Edi...

Qué es y a quién afecta

La CVE-2026-97229 es una vulnerabilidad de desbordamiento de entero (tipo CWE-190) en GitLab Community Edition y Enterprise Edition. Según la descripción recogida en la NVD del NIST, el fallo permitiría que un usuario no autenticado ejecute código arbitrario en el servidor de GitLab mediante una expresión regular especialmente construida dentro de una configuración de CI/CD, debido a una validación insuficiente de dichas expresiones.

Rack de servidores con la puerta entreabierta y un candado abierto, metáfora de una vulnerabilidad crítica sin cerrar

La gravedad asignada es CVSS 3.1 de 10 (CRITICAL), con un vector que refleja ataque por red, sin privilegios ni interacción del usuario y con impacto alto en confidencialidad, integridad y disponibilidad. Estamos, por tanto, ante una de esas vulnerabilidades que conviene tratar como prioridad absoluta si su organización aloja GitLab.

Las versiones afectadas, tal como las detalla la NVD, son:

  • GitLab CE/EE desde 19.2.0 (incluida) hasta 19.2.8 (sin incluir).
  • GitLab CE/EE desde 19.3.0 (incluida) hasta 19.3.5 (sin incluir).
  • GitLab CE/EE desde 19.4.0 (incluida) hasta 19.4.2 (sin incluir).

Esto incluye tanto instalaciones autogestionadas en servidores propios como entornos con un equipo de IT reducido que mantiene GitLab como herramienta interna de desarrollo.

Por qué es urgente: ya se explota en ataques reales

El dato más relevante no es solo la puntuación CVSS, sino que CISA añadió la CVE-2026-97229 a su catálogo KEV (Known Exploited Vulnerabilities) el 29 de octubre de 2026. Es decir, hay constancia de explotación activa en ataques reales, no se trata de una amenaza teórica.

El plazo que CISA da a las agencias federales de EE. UU. para corregirla vencía el 1 de noviembre de 2026, apenas unos días después de su inclusión. Esa urgencia debería trasladarse, con criterio proporcional, a cualquier empresa española que tenga GitLab expuesto: cuanto antes se apliquen las mitigaciones indicadas por el fabricante, mejor. CISA exige aplicar las mitigaciones conforme a las instrucciones del proveedor y evaluar la exposición a internet de cada activo.

En el material consultado no consta uso conocido de esta vulnerabilidad en campañas de ransomware, pero eso no rebaja la prioridad: la ejecución remota de código sin autenticación en un servidor de control de versiones abre la puerta a comprometer repositorios, credenciales y pipelines de despliegue.

Qué hacer hoy

La secuencia de actuación debería ser rápida y ordenada:

  • Comprobar si se usa GitLab y en qué versión. Revise instalaciones autogestionadas, incluidas las que quizá mantiene un proveedor externo o un compañero de IT a tiempo parcial. Si la versión cae dentro de los rangos 19.2.x, 19.3.x o 19.4.x indicados, está afectada.
  • Aplicar la actualización o mitigación del aviso del fabricante. GitLab publicó notas de parche para la versión 19.4.2; consulte siempre el aviso oficial y aplique exactamente lo que indique, sin improvisar versiones intermedias.
  • Revisar indicios de intrusión. Dado que el fallo se ejecuta a través de configuraciones de CI/CD, conviene revisar pipelines, ejecutores y registros de acceso en busca de actividad anómala, especialmente si el servidor ha estado accesible desde internet.
  • Reducir lo expuesto. Restrinja el acceso al servidor GitLab a las redes y usuarios que realmente lo necesiten, y valore si las mitigaciones disponibles son suficientes o si procede suspender temporalmente el servicio expuesto hasta poder actualizar.

No olvide documentar el cambio y verificar después que la versión instalada ya no está en los rangos afectados. En un entorno con RGPD y LOPDGDD de por medio, un compromiso del servidor de código puede derivar en brecha de datos y en obligaciones de notificación que conviene evitar.

Cómo puede ayudar un equipo de ciberseguridad como el de ALMC

En ALMC trabajamos con pymes, comercios online y empresas de Cataluña —Lleida, Barcelona, Tarragona, Girona— que tienen webs y servidores propios, a menudo sin un departamento de IT dedicado. Ante una vulnerabilidad crítica y explotada como esta, nuestro enfoque pasa por detectar y cerrar la exposición antes de que la exploten: auditorías de seguridad y pentesting para localizar servicios vulnerables, hardening de servidores para reducir la superficie de ataque, monitorización y respuesta a incidentes si hay sospecha de intrusión, y mantenimiento y actualización de las plataformas que sostienen su negocio.

Si su equipo técnico es pequeño o está desbordado, podemos encargarnos de verificar versiones, aplicar parches siguiendo el aviso del fabricante y revisar indicios de compromiso con un plan claro de prioridades. También reparamos webs y entornos hackeados cuando el incidente ya ha ocurrido, pero el objetivo real es que no llegue a ese punto.

Relacionado

¿Está tu empresa expuesta a fallos como este?

En ALMC revisamos qué versiones tienes publicadas, aplicamos los parches y endurecemos tus servidores y tu web. Descubre nuestros servicios de ciberseguridad o contáctanos para una revisión.