GitLab CVE-2026-97229: CISA la incluye como explotada y Alpine Linux muestra que actualizar no siempre basta

CISA ha añadido CVE-2026-97229, una falla de GitLab con CVSS 10.0, a su catálogo de vulnerabilidades explotadas. Alpine Linux informa de un intento de ataque contra su propio servidor, que siguió siendo vulnerable tras una actualización porque la corrección depende también de la versión de Ruby.

Qué ha pasado

El 29 de octubre de 2026, CISA añadió CVE-2026-97229 a su catálogo de vulnerabilidades explotadas: las agencias federales de EE. UU. tienen hasta el 1 de noviembre para actuar y deben realizar un análisis forense. GitLab la califica de crítica, con una puntuación CVSS de 10,0: un desbordamiento de entero en el compilador de expresiones regulares de la configuración CI/CD permite, en determinadas condiciones, que un usuario no autenticado ejecute código en el servidor. GitLab la corrigió el 12 de octubre en 19.4.2, 19.3.5 y 19.2.8. Alpine Linux indicó el 28 de octubre que un atacante intentó explotarla contra el servidor GitLab del proyecto los días 20 y 21 de octubre.

A quién afecta y cómo entran los atacantes

Afecta a las ediciones Community y Enterprise autogestionadas desde la 19.2; GitLab.com y Dedicated ya están corregidos. El fallo está en Onigmo, el motor de expresiones regulares integrado en Ruby, y la corrección de GitLab modifica el Ruby incluido en sus paquetes e imágenes oficiales. Alpine instaló primero la 19.3.4 por error y después la 19.3.6 en una imagen basada en Ruby estándar, que no contenía la corrección. Con una cuenta nueva y configuraciones CI manipuladas, el atacante hizo fallar ocho veces los procesos de GitLab. Alpine no halló pruebas de ejecución de código, pero no pudo descartarla, de modo que reconstruyó el servidor desde cero, restableció todas las contraseñas y sustituyó las claves secretas de GitLab. Afirma que sus versiones y paquetes se verificaron y no fueron modificados, y que las claves de firma nunca estuvieron en ese servidor.

Qué hacer ahora

1. Compruebe su versión con sudo gitlab-rake gitlab:env:info.
2. Actualice al último parche de su rama: 19.5.3, 19.4.5, 19.3.7 o 19.2.10.
3. Si compila GitLab usted mismo (desde el código fuente o en su propio contenedor), revise ruby -v: necesita 3.3.13, 3.4.12, 4.0.9 o posterior. Vuelva a descargar alpinelinux/gitlab:19.3.6 si la obtuvo antes del 27 de octubre; las etiquetas anteriores son vulnerables.
4. Busque rastros: aplique las seis reglas de detección publicadas por GitLab y revise los fallos de procesos, los errores 502, los trabajos CI fallidos y las cuentas registradas recientemente. Un resultado limpio prueba poco: según Alpine, una explotación exitosa no deja ningún fallo ni rastro en los registros web.
5. En caso de duda, reconstruya y sustituya claves secretas, contraseñas, variables CI/CD, tokens de runners y secretos de webhooks. Exija la aprobación de un administrador para las cuentas nuevas.
6. Revise sus demás aplicaciones Ruby: el código que pasa datos no fiables a Regexp.new, Regexp.union o a un patrón interpolado necesita un Ruby corregido. Según el equipo de Ruby, ni Regexp.timeout ni un límite de longitud protegen de forma fiable.

Nuestra opinión

Un número de versión no demuestra que un servidor esté corregido cuando la corrección reside en una dependencia: la comprobación debe abarcar toda la compilación, sobre todo en imágenes propias. Una forja reúne código fuente y secretos de despliegue, y no debería quedar abierta a todo Internet. Conserve suficientes registros, incluidas las conexiones salientes, para poder responder cuando surja la duda de un compromiso.

Fuentes

• GitLab — Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
• CISA — Known Exploited Vulnerabilities Catalog: CVE-2026-97229
• Alpine Linux — GitLab security incident: attempted exploitation of CVE-2026-97229
• Alpine Linux — GitLab is back: what you need to do
• Ruby — Regexp fixes for GitLab CVEs
• GitLab — Patch Release 19.5.3

Cómo elegimos, verificamos y redactamos nuestros análisis →