El proyecto Alpine Linux informó el 28 de octubre que un atacante intentó explotar una vulnerabilidad crítica en GitLab en su propio servidor GitLab, una semana después de que GitLab publicara un parche. La falla, identificada como CVE-2026-97229 y con una puntuación CVSS de 10.0, permite a un atacante ejecutar código en un servidor GitLab mediante una expresión regular manipulada en una configuración de CI. Alpine no halló pruebas de que el ataque tuviera éxito, pero no puede descartarlo, por lo que reconstruyó el servidor desde cero y restableció la contraseña de todas las cuentas.
El parche de GitLab consiste en una serie de actualizaciones para el intérprete Ruby que GitLab incluye en sus propios paquetes e imágenes de contenedor. La imagen de GitLab de Alpine utilizaba Ruby estándar, por lo que actualizar el servidor a GitLab 19.3.6 el 22 de octubre no corrigió la vulnerabilidad. Para quienes ejecutan GitLab sobre su propio Ruby, ya sea compilado desde el código fuente o en su propia imagen de contenedor, 'actualizar GitLab no es suficiente', según Alpine. Esos servidores también necesitan Ruby 3.3.13, 3.4.12, 4.0.9 o versiones posteriores, y los usuarios de la imagen alpinelinux/gitlab deben volver a descargar la versión 19.3.6.
El servidor gitlab.alpinelinux.org aloja aports, el repositorio desde el cual se construyen los paquetes de Alpine. Según Alpine, los paquetes construidos entre el 20 y el 24 de octubre, así como las versiones publicadas el 21 de octubre, provienen de cambios en aports verificados contra registros externos a GitLab. Esas versiones incluyen los archivos minirootfs a partir de los cuales se construyen las imágenes oficiales de Docker de Alpine. Alpine está extendiendo las verificaciones hasta el 27 de octubre, cuando cerró el servidor. Las claves que firman sus paquetes y versiones nunca han estado en el servidor GitLab.
Cómo se desarrolló el ataque
El 13 de octubre, Alpine actualizó el servidor a GitLab 19.3.4 en lugar de 19.3.5, lo que calificó como un error. El servidor seguía en esa versión, sin el parche del 12 de octubre, cuando una cuenta recién registrada comenzó a sondearlo el 20 de octubre. La cuenta envió configuraciones de CI manipuladas al servidor los días 20 y 21 de octubre. Estas provocaron la caída de procesos trabajadores de GitLab en 8 ocasiones, y el ataque principal del 21 de octubre también causó errores 502 y fallos en los trabajos de CI.
Según Alpine, en 4 de esas caídas el atacante avanzó parcialmente en el exploit y falló en el siguiente paso. El atacante también descargó la imagen de contenedor de GitLab de Alpine, lo que, según la organización, 'sugiere que estaban ajustando el exploit a nuestra compilación exacta'. Alpine bloqueó la cuenta el 23 de octubre. El atacante regresó los días 25 y 26 de octubre e intentó volver a entrar, pero esos intentos fracasaron, según Alpine.
El 26 de octubre, Alpine descubrió que el servidor seguía siendo vulnerable después de su actualización del 22 de octubre a la versión 19.3.6. Al día siguiente, cerró GitLab a todos excepto a sus desarrolladores y servidores de compilación, y comenzó a reconstruirlo. La reconstrucción finalizó el 28 de octubre. Alpine también reemplazó las claves secretas de GitLab, y el servidor reconstruido ejecuta Ruby 3.3.13 o posterior, que incluye la corrección. Alpine lo está probando antes de reabrirlo al público.
Lo que Alpine puede y no puede descartar
Alpine no encontró indicios de que el código del atacante se ejecutara en el servidor. Las pruebas de temporización no mostraron retrasos; no había archivos, claves, hooks o procesos inesperados; y no se enviaron datos privados al atacante a través de ninguna solicitud web o de API que Alpine pueda ver. Sin embargo, no puede estar seguro. 'Un exploit exitoso no dejaría ninguna caída ni rastro en los registros web', afirmó Alpine. Algunos registros del día del ataque se han perdido, incluidos los registros de trabajos en segundo plano y el sistema de archivos del contenedor antiguo, y ni Alpine ni su proveedor de alojamiento registraron conexiones de red salientes.
Dado que la evidencia necesaria para confirmar la ejecución de código ya no existe, Alpine trató el servidor como comprometido y lo reconstruyó para eliminar cualquier acceso que un exploit exitoso pudiera haber dejado. Si el ataque hubiera tenido éxito, podrían haberse expuesto los siguientes datos:
- Direcciones de correo electrónico, nombres y direcciones IP de todos los usuarios
- Hashes de contraseñas
- Secretos de 2FA, variables de CI/CD y tokens de runners
- Credenciales de webhooks, integraciones y réplicas de push
- Tokens de acceso personal, que se almacenan como hashes
- Repositorios privados, e issues y merge requests confidenciales
Además del restablecimiento de contraseñas y las nuevas claves secretas, Alpine no ha dicho si se han reemplazado los tokens de runners, las variables de CI/CD, los tokens de acceso o las credenciales de integración almacenadas en el servidor. Para verificar sus paquetes, Alpine confirmó que cada cambio en aports añadido entre el 20 y el 22 de octubre llegó mediante un push registrado por un desarrollador conocido. Lo verificó contra registros a los que, según afirma, el atacante no podía acceder: una copia del repositorio de un desarrollador y los 45 servidores de compilación. Cada paquete construido entre el 20 y el 24 de octubre provino de cambios en aports tal como se publicaron en git.alpinelinux.org.
Por qué la actualización de GitLab no lo solucionó
GitLab compila las expresiones regulares en las configuraciones de CI con Ruby, y el error detrás de CVE-2026-97229 está en Onigmo, el motor de expresiones regulares integrado en Ruby. La versión de GitLab del 12 de octubre lo corrigió al parchear el Ruby dentro del paquete Linux y las imágenes de contenedor de GitLab. Las versiones corregidas de Ruby salieron el 22 y 23 de octubre.
Una actualización de GitLab no cambia el Ruby propio del servidor, por lo que una instalación de GitLab sobre Ruby estándar mantiene la vulnerabilidad hasta que se actualice el propio Ruby a una versión corregida, como descubrió Alpine. Los paquetes Linux corregidos de GitLab y sus imágenes de contenedor oficiales incluyen el Ruby parcheado. Una instalación compilada desde el código fuente, o una imagen de contenedor que instala Ruby por separado como hacía la de Alpine, no lo recibe. Hasta el 29 de octubre, ninguno de los anuncios de versiones parcheadas de GitLab del 12 y 21 de octubre indica a los administradores de instalaciones compiladas desde el código fuente que actualicen Ruby. La guía de instalación desde el código fuente de GitLab todavía enumera Ruby 3.2 como su versión mínima, y Ruby 3.2 alcanzó el fin de su vida útil en abril y no recibirá corrección.
Qué servidores GitLab están expuestos
El aviso de GitLab señala que, 'bajo ciertas condiciones', la falla podría haber permitido a un usuario no autenticado ejecutar código en el servidor. GitLab.com y GitLab Dedicated ya están parcheados. Rapid7 construyó un exploit funcional en un laboratorio y publicó código de prueba de concepto el 13 de octubre. El exploit ejecutaba comandos como el usuario git de GitLab en una imagen oficial de GitLab 19.4.1 sin parchear, pero la misma entrada no se ejecutaba en la imagen 19.4.2 parcheada.
Ese exploit requiere primero acceso de escritura: el atacante debe confirmar un archivo .gitlab-ci.yml malicioso y una ruta de archivo con caracteres UTF-8 en una rama de un proyecto público. Ese requisito no se aplica en servidores donde los nuevos usuarios pueden registrarse y crear proyectos. En la ruta probada por Rapid7, 'solo la solicitud final de lint de CI no requiere autenticación'. Las propias notas de detección de GitLab también indican que el atacante primero debe crear esa ruta de archivo mediante las API de repositorio habituales. Rapid7 aún no sabe cómo el ataque del informe original a GitLab, que sigue siendo privado, evita el paso de escritura. Alpine no ha dicho cómo llegaron las configuraciones de CI de su atacante a GitLab, ni si las cuentas nuevas podían crear proyectos públicos en su servidor. CVE-2026-97229 no estaba en el catálogo de vulnerabilidades explotadas conocidas de CISA en la actualización de este del 28 de octubre.
Qué deben hacer los administradores de GitLab
Las versiones de GitLab del 21 de octubre son las más recientes en cada rama enumerada a continuación, y también corrigen CVE-2026-110264, otra falla de expresiones regulares. Qué versión corrige un servidor depende de cómo esté instalado GitLab:
- Paquete Linux de GitLab o imágenes de contenedor oficiales: actualizar a la versión más reciente de su rama.
- Instalaciones compiladas desde el código fuente, o imágenes que instalan su propio Ruby: actualizar GitLab y actualizar Ruby a 3.3.13, 3.4.12, 4.0.9 o posterior. Ruby 3.2 no recibirá la corrección, por lo que los servidores que ejecutan 3.2 deben actualizarse a una de esas versiones.
El aviso de GitLab nombraba 19.3.4 como la versión corregida para la rama 19.3 cuando se publicó el 12 de octubre. Ahora nombra 19.3.5 y enumera 19.3.4 como afectada, por lo que los servidores que aún estén en 19.3.4 deben pasar a 19.3.6. Si un servidor no puede actualizarse de inmediato, Rapid7 sugiere restringir el acceso anónimo a proyectos públicos, impedir que usuarios no confiables creen o escriban en proyectos públicos, o bloquear la ruta de lint de CI. Esos pasos cubren solo la ruta de exploit de Rapid7 y no corrigen el compilador de expresiones regulares vulnerable, según la empresa.
GitLab ha publicado seis reglas de detección para intentos de explotación contra servidores autogestionados, escritas en formato Sigma. Cuatro de ellas, que GitLab marca como experimentales, buscan patrones hostiles en advertencias de regexp de CI y solicitudes GraphQL ciLint, rutas de archivo inusualmente largas con caracteres no ASCII, e informes de fallos de Ruby que apuntan a Onigmo. La guía que acompaña a esas reglas advierte que un exploit exitoso puede no dejar ninguna caída, y ofrece estos pasos adicionales:
- Buscar archivos propiedad del usuario git en /tmp, procesos hijos inesperados de Puma o Sidekiq, conexiones salientes y crontabs o claves SSH modificadas para el usuario git.
- Si hay signos de ejecución de código, tratar el servidor como comprometido y rotar los secretos en gitlab-secrets.json, todas las variables de CI/CD, todos los tokens de runners y todos los tokens de acceso.
- Limitar quién puede crear cuentas y tokens de acceso personal en el servidor.
Qué deben hacer los usuarios de Alpine
Los titulares de cuentas tendrán que establecer una nueva contraseña con '¿Olvidó su contraseña?' en la página de inicio de sesión cuando gitlab.alpinelinux.org vuelva a abrir, según Alpine. También ha observado intentos de inicio de sesión automatizados contra su GitLab utilizando contraseñas filtradas de otros sitios, y cualquiera que haya usado su contraseña de gitlab.alpinelinux.org en otro lugar debería cambiarla allí. Los usuarios de la imagen alpinelinux/gitlab deben volver a descargar alpinelinux/gitlab:19.3.6. La imagen publicada el 27 de octubre contiene Ruby 3.3.13, mientras que cualquier imagen 19.3.6 descargada antes de esa fecha, y todas las etiquetas anteriores, son vulnerables. Los propios paquetes Ruby de Alpine ya tienen la corrección: Ruby 3.4.12 en Alpine 3.22, 3.23, 3.24 y edge, y Ruby 3.3.13 en Alpine 3.21. Ejecutar apk upgrade lo instala. Los mantenedores de Ruby dicen que el error solo importa para programas que compilan una expresión regular a partir de texto controlado por un atacante, y que la configuración Regexp.timeout de Ruby no protege contra él.
Deja una respuesta