La vulnerabilidad crítica CVE-2026-97229 (CVSS 10.0) en el motor de expresiones regulares Onigmo integrado en Ruby se utilizó para atacar el servidor GitLab del proyecto Alpine Linux. Según Alpine Linux, entre el 20 y el 21 de octubre de 2026, una cuenta recién registrada envió configuraciones de CI especialmente diseñadas al servidor gitlab.alpinelinux.org. El problema clave: actualizar GitLab a la versión 19.3.6 no eliminó la vulnerabilidad, ya que la imagen de Alpine usaba el Ruby estándar y no el Ruby parcheado de los paquetes oficiales de GitLab. Los administradores de instalaciones de GitLab compiladas manualmente y de imágenes de contenedor personalizadas deben actualizar tanto GitLab como Ruby a las versiones 3.3.13, 3.4.12 o 4.0.9. La vulnerabilidad se añadió al catálogo CISA KEV el 29 de octubre de 2026. Ya habíamos hablado de esta vulnerabilidad anteriormente.
Esencia de la vulnerabilidad
Según el registro CVE, CVE-2026-97229 es un desbordamiento de entero (CWE-190) en el compilador de expresiones regulares Onigmo, que Ruby utiliza para procesar regex. GitLab compila expresiones regulares de las configuraciones CI/CD mediante Ruby, lo que permite que un atacante logre la ejecución de código arbitrario en el servidor a través de una expresión regular especialmente diseñada en el archivo .gitlab-ci.yml.
La vulnerabilidad afecta a GitLab CE/EE en las versiones:
- 19.2 hasta 19.2.8
- 19.3 hasta 19.3.5
- 19.4 hasta 19.4.2
Rapid7 reprodujo la cadena completa de explotación en la imagen oficial GitLab 19.4.1 CE, obteniendo ejecución de comandos en nombre del usuario de sistema git. En la imagen parcheada 19.4.2, la misma entrada no funcionó. Un detalle importante: en la ruta probada por Rapid7, el atacante primero debe colocar la configuración CI maliciosa y un archivo con caracteres UTF-8 en la ruta en un proyecto público: solo la solicitud final a CI lint no requiere autenticación. Este requisito desaparece en servidores donde los nuevos usuarios pueden registrarse y crear proyectos por sí mismos.
Cronología del ataque a Alpine Linux
Según Alpine Linux, los acontecimientos se desarrollaron de la siguiente manera:
- 13 de octubre: Alpine actualizó el servidor a GitLab 19.3.4 en lugar de 19.3.5 (error durante la actualización). El servidor quedó sin el parche publicado el 12 de octubre.
- 20–21 de octubre: una cuenta recién registrada envió configuraciones de CI especialmente diseñadas, provocando 8 cierres inesperados de procesos de trabajo de GitLab. En 4 de ellos, el atacante avanzó parcialmente en la cadena de explotación, pero no completó el siguiente paso. El ataque del 21 de octubre también provocó errores 502 y fallos en tareas de CI.
- 22 de octubre: Alpine actualizó el servidor a GitLab 19.3.6, pero la vulnerabilidad permaneció (no se actualizó el Ruby estándar).
- 23 de octubre: se bloqueó la cuenta del atacante.
- 25–26 de octubre: el atacante intentó recuperar el acceso, sin éxito.
- 26 de octubre: Alpine descubrió que el servidor seguía siendo vulnerable tras la actualización de GitLab.
- 27 de octubre: el servidor se cerró para todos salvo para los desarrolladores y los servidores de compilación.
- 28 de octubre: el servidor se reconstruyó por completo desde cero con Ruby 3.3.13, se sustituyeron todas las claves secretas y se restablecieron las contraseñas de todas las cuentas.
Alpine también registró que el atacante descargó la imagen de contenedor del proyecto GitLab, lo que, en opinión de Alpine, indica la preparación de un exploit para una compilación concreta.
Por qué la actualización de GitLab no ayudó
Esta es la lección central del incidente. El parche de GitLab del 12 de octubre incluía un Ruby corregido dentro de los paquetes oficiales de Linux y las imágenes de contenedor de GitLab. Sin embargo, Alpine utilizaba su propia imagen con el Ruby del sistema, y no con el Ruby de los paquetes de GitLab. La actualización de GitLab no afecta a un Ruby instalado por separado: el compilador de expresiones regulares Onigmo vulnerable permanece en su lugar.
De este modo, el ámbito del parche es bidimensional: los paquetes oficiales de GitLab contienen un Ruby corregido, mientras que las instalaciones compiladas manualmente y las imágenes de contenedor personalizadas requieren una actualización independiente de Ruby. Las versiones de Ruby corregidas — 3.3.13, 3.4.12 y 4.0.9 — se publicaron entre el 22 y el 23 de octubre. Al mismo tiempo, a 29 de octubre, ninguno de los boletines de GitLab para instalaciones compiladas manualmente indicaba la necesidad de actualizar Ruby, y la guía de instalación desde el código fuente seguía indicando Ruby 3.2 como versión mínima. Ruby 3.2 llegó al final de su ciclo de vida en abril de 2026 y no recibirá correcciones: los usuarios de esta rama deben migrar a una versión con soporte.
Qué se pudo y qué no se pudo determinar
Alpine no encontró indicios de ejecución de código por parte del atacante: las mediciones temporales no mostraron retardos, no se hallaron archivos, claves, hooks ni procesos ajenos. Sin embargo, Alpine no puede descartar una explotación satisfactoria. Como se indica en el informe del proyecto, un exploit exitoso no deja cierres anómalos ni rastros en los registros web. Parte de los registros de los días del ataque se ha perdido, incluidos los registros de tareas en segundo plano y el sistema de archivos del contenedor antiguo. Ni Alpine ni su proveedor de alojamiento registraban las conexiones de red salientes.
La ausencia de telemetría saliente y la incompletitud de los registros son factores clave que impidieron realizar un análisis forense limpio. Esto aumenta la importancia de las seis reglas de detección publicadas por GitLab para instancias autogestionadas y de las comprobaciones a nivel de host.
Si la explotación hubiera tenido éxito, podrían haberse visto comprometidos: direcciones de correo electrónico, nombres e IP de usuarios; hashes de contraseñas; secretos de 2FA; variables CI/CD y tokens de runners; credenciales de webhooks, integraciones y espejos; hashes de tokens de acceso personal; repositorios privados e incidencias confidenciales. Alpine subraya que las claves de firma de paquetes y de lanzamientos nunca se almacenaron en el servidor GitLab, y que todos los cambios en aports durante el periodo del ataque se verificaron contra registros externos.
Recomendaciones
Para administradores de GitLab
- Paquetes oficiales de Linux o imágenes de contenedor de GitLab: actualice a la última versión disponible para su rama (19.4.2, 19.3.5, 19.2.8 o posterior: las versiones publicadas el 21 de octubre también corrigen la vulnerabilidad independiente CVE-2026-110264).
- Instalaciones compiladas manualmente o imágenes con un Ruby propio: actualice tanto GitLab como Ruby a 3.3.13, 3.4.12 o 4.0.9. Ruby 3.2 no recibirá correcciones.
- Medidas temporales (según la recomendación de Rapid7): limite el acceso anónimo a proyectos públicos, prohíba a usuarios no confiables crear proyectos públicos, bloquee la ruta CI lint. Estos pasos solo cierran la ruta de explotación probada por Rapid7.
- Detección: utilice las seis reglas de detección de GitLab en formato Sigma. Compruebe la presencia de archivos del usuario git en /tmp, procesos hijo inesperados de Puma o Sidekiq, conexiones salientes, crontab modificados o claves SSH del usuario git.
- Si se detectan indicios de ejecución de código, considere el servidor comprometido y rote los secretos en gitlab-secrets.json, todas las variables CI/CD, los tokens de runners y los tokens de acceso.
Para usuarios de Alpine Linux
- Los usuarios de la imagen alpinelinux/gitlab deben volver a descargar la etiqueta 19.3.6: la imagen del 27 de octubre contiene Ruby 3.3.13, las descargas anteriores son vulnerables.
- Los paquetes Ruby en Alpine ya están corregidos: Ruby 3.4.12 en Alpine 3.22–3.24 y edge, Ruby 3.3.13 en Alpine 3.21. Es suficiente con ejecutar
apk upgrade. - Los propietarios de cuentas en gitlab.alpinelinux.org tendrán que restablecer su contraseña cuando el servidor vuelva a abrirse. Si la contraseña se utilizaba en otros sitios, también debe cambiarse allí.
El incidente de Alpine Linux muestra un escenario concreto y reproducible: actualizar GitLab sin actualizar Ruby deja el servidor vulnerable a CVE-2026-97229. Los administradores de instalaciones compiladas manualmente y de imágenes de contenedor personalizadas de GitLab deben comprobar de inmediato la versión de Ruby en sus servidores y actualizarla a 3.3.13, 3.4.12 o 4.0.9: la actualización de GitLab por sí sola no cierra esta vulnerabilidad.
