Alpine reconstruye GitLab tras intentos de RCE
Alpine reconstruyó GitLab tras intentos de explotar CVE-2026-97229. No encontró cambios en paquetes, pero los registros incompletos impiden descartar el compromiso.
El proyecto Alpine Linux reconstruyó su instancia de GitLab después de que un atacante intentara explotar CVE-2026-97229, una vulnerabilidad de ejecución remota de código (RCE) en la expresión regular de Ruby que procesa configuraciones de CI/CD. Los intentos se produjeron el 20 y 21 de octubre; Alpine no encontró pruebas de que el atacante ejecutara código ni modificara paquetes, pero reconoce que los registros disponibles no permiten descartar una intrusión. La respuesta fue reconstruir el servicio desde cero y restablecer las credenciales.
La cronología importa porque el incidente no se resolvió con un simple salto de versión. GitLab publicó una corrección el 12 de octubre, pero Alpine estaba usando 19.3.4 y se había saltado la versión 19.3.5 corregida. Además, la reparación dependía de un parche en Ruby, no solo del código propio de GitLab: la imagen de Alpine incorporaba una compilación de Ruby que aún no lo contenía. La actualización a GitLab 19.3.6 del 22 de octubre, por sí sola, tampoco cerró el agujero.
-InfraCrew dice: Que una etiqueta diga “fix” no ayuda mucho si debajo sigue viajando el intérprete vulnerable.-
Ocho caídas y una reconstrucción
Según el registro de Alpine, una cuenta recién creada envió configuraciones de CI/CD preparadas para activar el fallo. Los procesos de GitLab se cayeron ocho veces; en cuatro intentos, el atacante avanzó parte del exploit antes de fallar en el paso siguiente. También descargó la imagen de contenedor que usaba el proyecto, una señal de que estaba afinando el ataque para el entorno concreto, no lanzando una prueba al azar.
Alpine no afirma que el acceso tuviera éxito. Afirma algo más incómodo para quien debe decidir qué hacer después: no puede descartarlo. Faltan algunos registros de tareas y del sistema de archivos del contenedor anterior, y no existía telemetría de conexiones salientes. Como un exploit exitoso podía no dejar una caída visible ni una entrada en los logs web, reconstruir el servidor reducía el riesgo de conservar una persistencia que no podían observar.
-InfraCrew dice: Si no se registran las conexiones de salida, el silencio del servidor no es una declaración jurada.-
Qué quedó fuera del incidente
La investigación sí encontró señales útiles para acotar el impacto. Alpine comprobó los commits de aports, sus paquetes y los lanzamientos estables del 21 de octubre usando copias de desarrolladores y registros externos a GitLab; también contrastó el trabajo de 45 compiladores. El proyecto afirma que no halló paquetes ni imágenes oficiales manipulados. Las claves que firman paquetes y releases nunca estuvieron guardadas en el GitLab afectado, lo que separa el compromiso potencial de la infraestructura de desarrollo de una alteración demostrada de la cadena de distribución.
La organización cerró temporalmente GitLab, reconstruyó la instancia, cambió todas las contraseñas y sustituyó claves secretas. Lo reabrió el 29 de octubre con GitLab 19.3.7. Alpine también advirtió a los usuarios que reutilizaran la contraseña del servicio en otro sitio que la cambiasen allí: la rotación local no revoca credenciales filtradas en servicios ajenos.
La versión visible no siempre cuenta toda la historia
Para quienes ejecutan la imagen oficial alpinelinux/gitlab, la indicación concreta es volver a descargar la etiqueta 19.3.6 publicada el 27 de octubre; esa imagen ya incluye Ruby 3.3.13. Una imagen 19.3.6 obtenida antes de esa fecha y las etiquetas anteriores siguen vulnerables, aunque el nombre parezca el mismo. Quienes compilan GitLab con una versión propia de Ruby deben usar las ramas corregidas 3.3.13, 3.4.12 o 4.0.9, o una posterior.
El caso deja una diferencia práctica entre corregir el producto y corregir todas sus dependencias empaquetadas. En una instalación propia, conviene comprobar el contenido real de la imagen y el runtime que ejecuta el servicio, no fiarse únicamente de la etiqueta de GitLab. La exposición de paquetes de Alpine no se confirmó; el riesgo que motivó la reconstrucción fue la posible exposición de datos de cuentas, variables de CI/CD y credenciales de integración alojadas en la instancia.
Diccionario de la Crew
RCE — Ejecución remota de código: capacidad de hacer que un sistema ejecute instrucciones enviadas desde otro equipo.
CI/CD — Integración y entrega continuas: automatización que compila, prueba y publica cambios de software.
Ruby — Lenguaje de programación utilizado, entre otras cosas, por componentes internos de GitLab.
