La CVE-2026-97229 de GitLab casi le abre a un atacante el servidor de Alpine Linux, y la parte incómoda es esta: el equipo actualizó dos veces y el agujero siguió abierto. El parche no vivía en el código de GitLab. Vivía en Ruby, el lenguaje que corre debajo.
Alpine Linux contó el incidente el 28 de octubre con una franqueza poco común. Hubo un intento real de explotación los días 20 y 21 de octubre, una semana después de que GitLab publicara la corrección. No aparecieron pruebas de que el ataque funcionara, pero el proyecto no pudo descartarlo. La respuesta fue la más drástica: tratar la instancia como comprometida, cerrarla y rehacerla desde cero.
Un ataque con paciencia y ocho caídas
Todo arrancó el 20 de octubre. Una cuenta recién registrada envió configuraciones de CI con expresiones regulares maliciosas. Esas configuraciones tumbaron los procesos de GitLab ocho veces. En cuatro caídas, el atacante avanzó una parte del ataque y falló en el paso siguiente, detalló el equipo de infraestructura.
Otro detalle delata preparación. El atacante descargó la imagen de contenedor del propio GitLab de Alpine, un movimiento que el proyecto interpreta como un ajuste fino del ataque contra esa construcción. El 21 de octubre llegó el golpe fuerte: errores 502, trabajos de integración continua fallidos y más caídas. La cuenta quedó bloqueada el 23 de octubre. El atacante volvió el 25 y el 26, ya sin éxito.
La falla merece su nota de 10.0 sobre 10 en la escala CVSS. El error está en Onigmo, el motor de expresiones regulares integrado en Ruby, y GitLab evalúa con ese motor las expresiones escritas en la configuración de CI. Una expresión armada con intención puede terminar ejecutando código en el servidor. Rapid7 publicó una prueba de concepto el 13 de octubre y logró correr comandos con el usuario git en una imagen oficial sin parche. Ese servidor, gitlab.alpinelinux.org, guarda aports, el repositorio del que salen todos los paquetes de Alpine.
Por qué actualizar GitLab no bastó
GitLab publicó sus versiones corregidas el 12 de octubre. La corrección consiste en parches aplicados al Ruby que GitLab incluye en sus propios paquetes e imágenes oficiales. Quien instala esos paquetes recibe el Ruby remendado sin hacer nada extra. El problema aparece en las instalaciones que arman su propio Ruby. Ahí, subir de versión de GitLab no toca el Ruby del sistema.
Alpine cayó en esa trampa dos veces. El 13 de octubre subió su servidor a GitLab 19.3.4, cuando la versión con la corrección era la 19.3.5; el propio proyecto lo llama un error. El 22 de octubre subió a la 19.3.6 y el agujero siguió abierto, porque su imagen usaba un Ruby estándar. Ruby publicó su corrección el 23 de octubre en las versiones 3.3.13, 3.4.12 y 4.0.9. Recién el 26 de octubre el equipo descubrió que su instancia seguía vulnerable.
La lección viaja mucho más lejos que Alpine Linux. Miles de empresas en América Latina corren GitLab autohospedado, muchas con imágenes ajustadas a mano. Para ese grupo, la CVE-2026-97229 de GitLab exige revisar dos piezas, no una: la versión de GitLab y la de Ruby. Ruby 3.2 cerró su ciclo de vida en abril y no recibirá esta corrección, así que quedarse en esa rama deja la puerta abierta aunque GitLab se vea actualizado.
Qué revisar hoy en un GitLab propio
Quien use el paquete oficial de GitLab o sus imágenes oficiales solo necesita subir a la versión más reciente de su rama. Quien compile desde el código o mantenga una imagen propia debe mover Ruby a 3.3.13, 3.4.12 o 4.0.9 como mínimo. Los usuarios de la imagen alpinelinux/gitlab tienen una tarea puntual: descargar otra vez la etiqueta 19.3.6, porque la imagen republicada el 27 de octubre sí trae Ruby 3.3.13; cualquier copia bajada antes de esa fecha sigue vulnerable. Conviene recordar que este agujero convive con otra falla de GitLab que permite ejecutar código sin iniciar sesión, corregida en las versiones del 21 de octubre.
La verificación de daños trajo alivio parcial. El equipo revisó cada cambio de aports entre el 20 y el 22 de octubre contra registros guardados fuera de GitLab, incluido el clon de un desarrollador y los 45 servidores de construcción. Todos los paquetes armados entre el 20 y el 24 salieron de cambios verificados, y las versiones estables del 21 de octubre quedaron limpias. Las claves de firma nunca estuvieron en ese servidor.
Queda una zona gris que el proyecto admite sin rodeos. Una explotación exitosa no deja caída ni rastro en los registros web. Parte de los registros de esos días ya no existe, y nadie guardaba las conexiones salientes. Si el código del atacante corrió, pudo tocar correos, resúmenes de contraseñas, secretos de doble factor, variables de CI/CD y repositorios privados.
El cierre del incidente llegó el 28 de octubre: instancia rehecha, contraseñas restablecidas y claves secretas de GitLab reemplazadas. Quien tenga cuenta allí deberá crear una contraseña nueva cuando el servicio reabra, y cambiarla en cualquier otro sitio donde la haya repetido, porque el equipo ya vio intentos automatizados con contraseñas filtradas de otros servicios. La CVE-2026-97229 de GitLab deja una regla simple para cualquier administrador: un sistema no está parcheado hasta que lo está también cada pieza que lo sostiene, y Alpine Linux pagó esa comprobación con una semana de servidor cerrado.
Fuente: Alpine Linux
Foto: The Hacker News
