Se actualizaron, pero siguieron siendo vulnerables. Alpine Linux tuvo que reconstruir el servidor desde cero.

Los desarrolladores de Alpine Linux recrearon por completo su servidor GitLab tras un ataque que explotó una vulnerabilidad crítica con puntuación 10 de 10. El atacante interrumpió los flujos de trabajo del servicio ocho veces, y la actualización instalada por los administradores no solucionó el fallo peligroso.

El ataque comenzó el 20 de octubre de 2026. Un intruso registró una cuenta en gitlab.alpinelinux.org y envió configuraciones CI/CD especialmente preparadas que GitLab utiliza para la compilación y las pruebas automáticas del software. En cuatro de las ocho terminaciones anómalas de los flujos de trabajo, la explotación avanzó hasta la siguiente fase, pero luego se detuvo.

El objetivo fue CVE-2026-97229, que permite ejecutar código arbitrario de forma remota en el servidor sin autorización. El error está relacionado con un desbordamiento entero al procesar expresiones regulares por el motor Onigmo, integrado en Ruby. GitLab publicó correcciones el 12 de octubre, sin embargo el equipo de Alpine al día siguiente instaló por error la versión vulnerable 19.3.4 en vez de la protegida 19.3.5.

El atacante también descargó la imagen de contenedor de GitLab que usaba el proyecto. Es probable que adaptara el exploit a una compilación concreta. El ataque provocó errores 502 y fallos en los trabajos de CI. La cuenta fue bloqueada el 23 de octubre. Los intentos repetidos de intrusión el 25 y el 26 de octubre no dieron resultado.

El 22 de octubre GitLab se actualizó a 19.3.6. Cuatro días después los administradores descubrieron que el servidor seguía siendo vulnerable. La corrección afectaba no al código de GitLab, sino al intérprete Ruby que se incluye con los paquetes oficiales. El contenedor propio de Alpine usaba un Ruby genérico, por lo que el parche necesario no llegó al sistema.

No se encontraron indicios de ejecución de código ajeno o de robo de información, pero no pudieron descartar el compromiso. Parte de los registros habían desaparecido para el momento de la comprobación, y las conexiones salientes del servidor no se registraban. Una explotación exitosa podría no haber provocado fallos ni dejado rastros en los registros web. Por eso, el 27 de octubre se restringió el acceso a GitLab y se empezó a recrear el servidor.

Para el 28 de octubre se restauró la infraestructura, se cambiaron las claves secretas de GitLab y se restablecieron las contraseñas de todos los usuarios. Si el ataque hubiera tenido éxito, podrían haberse expuesto direcciones de correo electrónico, hashes de contraseñas, secretos de autenticación de dos factores, tokens y repositorios privados. Alpine recomienda cambiar la contraseña también en otros servicios si se usó la misma combinación.

En el publicado análisis del incidente los desarrolladores indicaron que no detectaron sustitución de paquetes, del repositorio aports ni de las versiones de Alpine del 21 de octubre. Comprobaron los commits con copias externas y con 45 servidores de compilación. Las claves de firma de paquetes nunca se almacenaron en el GitLab atacado.

Para GitLab compilados por cuenta propia, una actualización de la aplicación no es suficiente. Se requieren Ruby 3.3.13, 3.4.12, 4.0.9 o versiones posteriores. Los usuarios de la imagen alpinelinux/gitlab:19.3.6 deben descargar de nuevo la publicación del 27 de octubre. La imagen anterior con la misma etiqueta sigue siendo vulnerable. Los desarrolladores de Alpine planean instalar antes los parches críticos y conservar los registros por más tiempo.