CISA confirma que ya se explota en internet, más de 1.000 servidores siguen expuestos y el caso de Alpine Linux demuestra que actualizar GitLab no siempre basta.
Qué ha pasado
El 29 de octubre de 2026, la agencia estadounidense CISA añadió el CVE-2026-97229 a su catálogo de vulnerabilidades explotadas conocidas (KEV): hay evidencia de explotación activa. Afecta a las instalaciones autogestionadas de GitLab Community Edition y Enterprise Edition y tiene la puntuación máxima posible, CVSS 10.0.
GitLab publicó el parche el 12 de octubre, en las versiones 19.4.2, 19.3.5 y 19.2.8, y recomendó actualizar «inmediatamente». Tres semanas después, Shadowserver seguía contando más de 1.000 servidores expuestos a internet sin parchear, y la fecha límite de CISA, el 1 de noviembre, ya ha pasado.
El fallo
El CVE-2026-97229 es un desbordamiento de enteros en el compilador de expresiones regulares de CI/CD de GitLab, el componente que evalúa las expresiones regulares de los archivos de pipeline. La raíz está en Onigmo, el motor de expresiones regulares de Ruby, que GitLab incluye en sus paquetes.
Un atacante sin cuenta puede enviar una expresión regular especialmente construida en una configuración de CI/CD y ejecutar código arbitrario en el servidor. No hace falta autenticarse ni interacción de la víctima: el ataque llega por red. Lo descubrió el investigador «joaxcar» a través del programa de bug bounty de GitLab en HackerOne, y Rapid7 publicó una prueba de concepto el 13 de octubre.
El caso Alpine Linux: actualizar no fue suficiente
Entre el 20 y el 21 de octubre, una cuenta recién registrada envió configuraciones de CI maliciosas contra el servidor GitLab de Alpine Linux, que corría GitLab 19.3.4: Alpine había instalado por error la 19.3.4 en lugar de la 19.3.5, que contenía el parche.
Los ataques provocaron ocho caídas de los procesos worker, y cuatro intentos mostraron signos de éxito parcial. Alpine no encontró pruebas de que el atacante ejecutara código ni manipulara paquetes, pero tampoco pudo descartarlo: faltaban registros y no había constancia de las conexiones salientes. Ante esa incertidumbre, reconstruyó su instancia de GitLab desde cero, restableció todas las contraseñas y sustituyó las claves secretas.
Tras el ataque, Alpine actualizó a GitLab 19.3.6… y seguía siendo vulnerable. El parche venía dentro del Ruby empaquetado de GitLab, pero la imagen de contenedor propia de Alpine usaba el Ruby estándar, sin ese parche. Solo la imagen publicada el 27 de octubre, que incluye Ruby 3.3.13, cerró el agujero.
El alcance: más de 1.000 servidores con este fallo y más de 11.000 con otro
Shadowserver, que rastrea a diario unas 39.000 instancias de GitLab visibles en internet, publicó el 1 de noviembre sus cifras: más de 1.000 instancias seguían siendo vulnerables al CVE-2026-97229, y más de 11.300 lo eran a un segundo fallo, el CVE-2026-110264.
Ese segundo fallo es otro desbordamiento de enteros en el mismo compilador de expresiones regulares, también con CVSS 10.0 y también descubierto por joaxcar. GitLab lo corrigió el 21 de octubre en las versiones 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13, y afecta a todas las versiones desde la 7.0. Quien parcheó el 12 de octubre sigue expuesto a un segundo fallo de severidad máxima. CISA aún no lo ha incluido en el KEV, pero eso refleja solo la evidencia de explotación de la que dispone, no el riesgo.
Qué hacer ahora
Si gestionas un GitLab autogestionado, este es el orden:
- Actualiza a la última versión de parche. A 2 de noviembre, las más recientes son 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 y 18.11.14, publicadas el 29 de octubre. No te quedes en las versiones del 12 de octubre: no corrigen el segundo fallo.
- Verifica el Ruby que corre debajo. Si usas imágenes propias o una instalación desde el código fuente, confirma Ruby 4.0.9, 3.4.12 o 3.3.13 (o superior).
- Si tu instancia estuvo expuesta a internet con una versión vulnerable, asume compromiso potencial. En un servidor propio, eso daría acceso a variables de CI/CD, claves de despliegue, tokens y el código de todos los proyectos. GitLab.com ya está parcheado y los clientes de GitLab Dedicated no tienen que hacer nada.
- Rota los secretos después de parchear, no antes: si el servidor sigue vulnerable, los nuevos se robarían igual.
- Si no puedes parchear hoy, reduce la exposición: pon el servidor detrás de una VPN o una lista de IPs permitidas.
Ángulo Blue Team: qué vigilaría un SOC
GitLab publicó seis detecciones de amenazas para el CVE-2026-97229 y dos más para el CVE-2026-110264, todas centradas en lo mismo: caídas de procesos worker y errores anómalos en el lint de CI.
El patrón común es claro: caídas inesperadas de procesos worker y ráfagas de errores de lint de CI. Eso es lo que Alpine vio el 20 y 21 de octubre, y es lo que un SOC debería tener alertado: un pico de errores 502 o de trabajos de CI fallidos puede ser el primer síntoma de que alguien está probando el exploit, no un simple fallo de infraestructura.
Conviene vigilar además cuentas nuevas que envíen configuraciones de CI sospechosas. Y si tus registros no te permitirían reconstruir hoy qué pasó durante un ataque, como le ocurrió a Alpine, tienes un problema de visibilidad que resolver antes del próximo incidente.
Fuentes
- BleepingComputer — «Over 1,000 GitLab servers vulnerable to ongoing RCE attacks» (2 de noviembre de 2026)
- BleepingComputer — «CISA says max severity GitLab flaw now exploited in the wild» (30 de octubre de 2026)
- Digital Matters — «GitLab Vulnerability CVE-2026-97229 Is Being Exploited: Why 19.4.2 Is Not Enough» (4 de noviembre de 2026)
- SC Media — «Over 1,000 GitLab servers exposed to exploited critical RCE flaw» (2 de noviembre de 2026)
- Alpine Linux / PBX Science — «Alpine Linux Rebuilds Its GitLab Server After Attempted CVE-2026-97229 Attack» (4 de noviembre de 2026)
- SC Media — «Alpine Linux rebuilds GitLab instance following exploit attempts» (2 de noviembre de 2026)