Un atacante intentó explotar la vulnerabilidad crítica CVE-2026-97229 en el servidor GitLab del proyecto Alpine Linux. Ocurrió una semana después de que GitLab publicara la corrección. Alpine no encontró pruebas de éxito, pero tampoco puede descartarlo. Por eso reconstruyó el servidor desde cero y restableció todas las contraseñas. El caso deja una lección para cualquier empresa con GitLab propio: actualizar GitLab no siempre corrige la falla.
La vulnerabilidad tiene puntuación CVSS de 10.0, el máximo en la escala estándar de gravedad. Permite ejecutar código en el servidor mediante una expresión regular manipulada dentro de una configuración de CI (integración continua, el proceso que compila y prueba el código automáticamente). El error es un desbordamiento de enteros en Onigmo, el motor de expresiones regulares incluido en Ruby. GitLab lo corrigió el 12 de octubre parcheando el Ruby que distribuye en su paquete Linux y en sus imágenes oficiales de contenedor. Las instalaciones compiladas desde el código fuente, o las imágenes que instalan Ruby por separado, no reciben ese parche. Era el caso de Alpine: su actualización a GitLab 19.3.6 del 22 de octubre dejó el servidor vulnerable. Rapid7 publicó una prueba de concepto que exige escribir primero un archivo .gitlab-ci.yml malicioso en un proyecto público. Ese requisito desaparece en servidores donde cualquiera puede registrarse y crear proyectos.
En Alpine, una cuenta recién registrada envió configuraciones manipuladas el 20 y 21 de octubre. Provocó 8 caídas de procesos de GitLab y, en 4 de ellas, avanzó parcialmente en el ataque. También descargó la imagen de contenedor de Alpine, lo que sugiere que ajustaba el ataque a esa versión exacta. Alpine no halló archivos, claves ni procesos extraños. Sin embargo, perdió parte de los registros del día del ataque y nadie registraba las conexiones salientes. Un ataque exitoso podría haber expuesto hashes de contraseñas, secretos de doble factor, variables de CI/CD, tokens de ejecutores y repositorios privados. Alpine verificó sus paquetes contra registros externos a GitLab, y sus claves de firma nunca estuvieron en ese servidor.
Las versiones más recientes de cada rama, del 21 de octubre, son 19.5.1, 19.4.3, 19.3.6 y 19.2.9. También corrigen CVE-2026-110264, otra falla de expresiones regulares. Quien use el paquete Linux o las imágenes oficiales debe actualizar a la última versión de su rama. Los servidores en 19.3.4 deben pasar a 19.3.6, porque GitLab ahora lista esa versión como afectada.
Quien compile GitLab o use su propio Ruby debe además actualizar Ruby a 3.3.13, 3.4.12, 4.0.9 o posterior. Ruby 3.2 llegó al final de su vida útil y no recibirá corrección.
Los usuarios de la imagen alpinelinux/gitlab deben descargar de nuevo la etiqueta 19.3.6 publicada el 27 de octubre. Si no es posible actualizar ya, Rapid7 sugiere restringir el acceso anónimo a proyectos públicos, impedir que usuarios no confiables creen proyectos o bloquear la ruta de CI lint.
GitLab publicó seis reglas de detección en formato Sigma. También recomienda buscar archivos del usuario git en /tmp, procesos hijos inesperados de Puma o Sidekiq, conexiones salientes y cambios en crontabs o llaves SSH. Ante cualquier indicio, conviene rotar gitlab-secrets.json, variables de CI/CD, tokens de ejecutores y tokens de acceso.
Qué significa para tu empresa: si alojan GitLab propio, verifiquen esta semana cómo está instalado y qué versión de Ruby ejecuta realmente, no solo la versión de GitLab. Revisen también si el registro de usuarios está abierto. El caso de Alpine muestra que, sin registros conservados de forma centralizada y sin control del tráfico saliente, es imposible confirmar o descartar un compromiso. Una estrategia de analítica de logs que retenga eventos de aplicaciones y conexiones salientes fuera del servidor afectado hace la diferencia entre investigar con evidencia y tener que reconstruir todo a ciegas.
Fuente original: The Hacker News — ver artículo →