Alpine Linux reconstruye GitLab tras un intento de exploit crítico de regex en Ruby

Alpine Linux anunció el 28 de octubre que había reconstruido por completo su servidor GitLab y restablecido todas las contraseñas de usuario tras un ataque dirigido que explotaba una vulnerabilidad crítica. El incidente pone de manifiesto una peligrosa brecha en los procedimientos de parcheo para instancias autogestionadas, donde el entorno de ejecución subyacente de Ruby permanece vulnerable incluso después de actualizar la propia aplicación GitLab.

Qué ocurrió

Un atacante intentó explotar CVE-2026-97229, una falla con una puntuación perfecta de CVSS de 10.0, en la instancia de GitLab de Alpine que aloja el repositorio aports. La vulnerabilidad permite la ejecución remota de código mediante expresiones regulares manipuladas en configuraciones de CI. Aunque Alpine no encontró evidencia definitiva de que el atacante hubiera ejecutado código con éxito, no pudieron descartarlo debido a la falta de registros y a la naturaleza del exploit. En consecuencia, trataron el servidor como comprometido, lo apagaron el 27 de octubre y completaron una reconstrucción total el 28 de octubre.

El ataque comenzó el 20 de octubre, solo una semana después de que GitLab lanzara una corrección. Una cuenta recién registrada sondeó el servidor, enviando configuraciones de CI maliciosas que provocaron fallos en los procesos de trabajo ocho veces. El 21 de octubre, el atacante causó errores 502 y fallos en los trabajos de CI. Alpine bloqueó la cuenta el 23 de octubre, pero el atacante regresó los días 25 y 26 de octubre. Crucialmente, Alpine descubrió el 26 de octubre que su actualización a GitLab 19.3.6 realizada el 22 de octubre no había corregido realmente la vulnerabilidad porque su instalación utilizaba un Ruby estándar del sistema en lugar de la versión parcheada incluida en los paquetes oficiales de GitLab.

Cómo funciona

La causa raíz reside en Onigmo, el motor de expresiones regulares integrado en Ruby. CVE-2026-97229 es un error en este motor que puede ser activado por patrones específicos de expresión regular proporcionados por un atacante en un archivo de configuración de CI. Cuando GitLab procesa estas configuraciones, compila la expresión regular utilizando Ruby. Si la versión de Ruby es vulnerable, este paso de compilación puede derivar en la ejecución remota de código.

GitLab abordó esto en su lanzamiento del 12 de octubre parcheando el intérprete de Ruby incluido en sus paquetes oficiales para Linux e imágenes de contenedor. Sin embargo, muchos administradores, incluido el equipo de Alpine, ejecutan GitLab sobre su propio Ruby instalado en el sistema o imágenes de contenedor personalizadas. En estas configuraciones, actualizar el código de la aplicación GitLab no actualiza el intérprete de Ruby subyacente. Dado que la corrección reside en el propio lenguaje Ruby, los servidores que ejecutan versiones sin parchear de Ruby permanecen expuestos independientemente de la versión de GitLab instalada. La imagen de Alpine usaba Ruby estándar, por lo que su actualización de GitLab dejó intacto el motor vulnerable hasta que actualizaron explícitamente Ruby a la versión 3.3.13, 3.4.12 o posterior.

Detalles clave

• Vulnerabilidad: CVE-2026-97229 (CVSS 10.0) en el motor de regex Onigmo de Ruby.
• Vector de ataque: Expresiones regulares manipuladas en archivos .gitlab-ci.yml enviados mediante la configuración de CI.
• Brecha de parcheo: Actualizar únicamente GitLab es insuficiente para instalaciones compiladas manualmente o imágenes personalizadas; Ruby debe actualizarse a 3.3.13, 3.4.12, 4.0.9 o posterior.
• Cronología del incidente: Las sondas de ataque comenzaron el 20 de octubre; el servidor se cerró el 27 de octubre; la reconstrucción finalizó el 28 de octubre.
• Riesgo de datos: La exposición potencial incluye correos electrónicos de usuarios, hashes de contraseñas, secretos de 2FA, variables de CI/CD y repositorios privados si hubo ejecución de código.
• Verificación: Alpine verificó la integridad de los paquetes entre el 20 y el 24 de octubre contra registros externos, confirmando que no hubo compromiso de la cadena de suministro en los paquetes construidos.

Por qué importa

Este incidente sirve como un claro recordatorio para los equipos de ingeniería que gestionan infraestructuras autoalojadas. Expone un punto ciego común en la gestión de dependencias: asumir que actualizar una aplicación asegura automáticamente su entorno de ejecución. Para los desarrolladores que crean productos con IA o pipelines complejos de CI/CD, comprender la distinción entre parches a nivel de aplicación y parches a nivel de runtime es crítico. No actualizar el intérprete de lenguaje subyacente puede dejar un sistema completamente abierto a exploits críticos, incluso cuando el proveedor de la aplicación afirma que el problema está resuelto.

Además, la ambigüedad del resultado subraya la dificultad del análisis forense en entornos nativos de nube. Debido a que un exploit exitoso de esta naturaleza podría no dejar rastros tradicionales como fallos o entradas en los logs, las organizaciones deben adoptar un enfoque de confianza cero en la respuesta a incidentes. La decisión de Alpine de reconstruir desde cero en lugar de intentar limpiar ilustra el alto costo operativo de tales vulnerabilidades. Para fundadores técnicos y líderes de TI, esto refuerza la necesidad de registros robustos, prácticas de infraestructura inmutable y verificación rigurosa de todos los componentes en la cadena de suministro de software.

Qué puedes hacer

• Comprueba tu versión de Ruby: Si ejecutas GitLab compilado manualmente o contenedores personalizados, asegúrate de actualizar Ruby inmediatamente a 3.3.13, 3.4.12, 4.0.9 o posterior.
• Verifica las actualizaciones de GitLab: Confirma que tu método de instalación de GitLab incluye el Ruby parcheado. Si no es así, actualiza manualmente el Ruby del sistema.
• Rota los secretos: Si sospechas de una exposición, rota todas las variables de CI/CD, tokens de runners, tokens de acceso personal y credenciales de webhooks.
• Restringe el acceso: Limita el acceso anónimo a proyectos públicos e impide que usuarios no confiables creen o escriban en repositorios públicos.
• Monitorea indicadores: Utiliza las reglas de detección Sigma publicadas por GitLab para buscar patrones de regex hostiles, rutas de archivo inusualmente largas con caracteres no ASCII y reportes de fallos de Ruby.
• Extrae imágenes actualizadas: Si usas la imagen de GitLab de Alpine, vuelve a extraer alpinelinux/gitlab:19.3.6, asegurándote de que fue publicada después del 27 de octubre para incluir el Ruby corregido.