El proyecto Alpine Linux ha reconstruido desde cero su instancia de GitLab y ha restablecido todas las contraseñas tras detectar los días 20 y 21 de octubre intentos de explotar CVE-2026-97229, un fallo de ejecución remota de código de máxima gravedad, que llegaron a tumbar procesos del servidor. Alpine asegura que no ha encontrado pruebas de que se ejecutara código ni de manipulación en paquetes o versiones publicadas, pero reconoce que no puede descartar del todo el compromiso porque faltan registros.
Las claves del incidente de seguridad en el GitLab de Alpine Linux en 30 segundos
- Un atacante envió configuraciones de CI/CD maliciosas al GitLab de Alpine los días 20 y 21 de octubre para explotar CVE-2026-97229.
- Alpine había actualizado a versiones que no cerraban el fallo, porque su imagen propia no incluía el parche de Ruby.
- No hay pruebas de manipulación de paquetes y las claves de firma no estaban en ese servidor.
- Alpine ha reconstruido GitLab, ha restablecido las contraseñas y pide a sus usuarios que cambien la suya.
El GitLab de Alpine aloja los repositorios de desarrollo, las revisiones de código y los trabajos de integración continua del proyecto, incluido aports, el conjunto de recetas con las que se construyen sus paquetes. Alpine es una distribución muy usada como base de imágenes de contenedor, por lo que cualquier incidente en su infraestructura de desarrollo tiene una lectura de cadena de suministro. Según BleepingComputer, el atacante llegó a descargar la imagen de contenedor de GitLab que usa Alpine, un paso que podría apuntar a la preparación de un ataque de ese tipo.
Un fallo crítico en el compilador de expresiones regulares
CVE-2026-97229 es un desbordamiento de entero en Onigmo, el motor de expresiones regulares que Ruby incluye y que GitLab usa al procesar la configuración de CI/CD. Un atacante sin autenticar podía aprovecharlo, en determinadas condiciones, enviando una expresión regular manipulada en la configuración de un pipeline para ejecutar código en el servidor. Tiene una puntuación CVSS de 10 y afecta a GitLab Community Edition y Enterprise Edition: según The Hacker News, GitLab lo corrigió el 12 de octubre en las versiones 19.4.2, 19.3.5 y 19.2.8.
Ese mismo paquete de correcciones incluía otros tres fallos de gravedad alta: un XSS (CVE-2026-92883), un problema de autorización que permitía a un desarrollador lanzar pipelines en ramas protegidas (CVE-2026-16301) y otro de envenenamiento de caché que podía exponer variables de entorno protegidas (CVE-2026-14814).
Por qué Alpine siguió expuesto tras actualizar
El caso de Alpine muestra lo que puede fallar al parchear. Según el relato de BleepingComputer basado en el aviso del propio proyecto, Alpine instaló primero GitLab 19.3.4 en lugar de la 19.3.5 corregida. Después actualizó a la 19.3.6, pero el fallo seguía abierto: la corrección dependía de un parche de Ruby que los paquetes oficiales de GitLab sí incluían y que la imagen de contenedor propia de Alpine no tenía.
Con esa ventana abierta, el atacante envió configuraciones de CI maliciosas que provocaron ocho caídas de procesos de trabajo de GitLab; cuatro de los intentos tuvieron un éxito parcial, aunque ninguno parece haberse completado. Alpine no ha encontrado manipulación en commits, paquetes ni versiones hasta el 27 de octubre, y aclara que las claves de firma de paquetes no se guardan en el servidor de GitLab, así que no pudieron quedar expuestas. Sin embargo, la falta de registros y de datos sobre conexiones salientes impide descartar una intrusión. Si hubiera tenido éxito, habrían podido quedar expuestos datos de usuarios, hashes de contraseñas, secretos de doble factor y de CI/CD, credenciales de integraciones y el contenido de proyectos privados, algo que no se ha confirmado. Por eso, explica el proyecto, eligió el camino más difícil y reconstruyó la instancia desde cero.
Qué deben hacer usuarios y administradores de GitLab
- Quien tenga cuenta en el GitLab de Alpine debe restablecer su contraseña.
- Quien use la imagen
alpinelinux/gitlabdebe pasar a la etiqueta 19.3.6 publicada el 27 de octubre, que incluye Ruby 3.3.13 y corrige CVE-2026-97229. - Cualquier administrador de GitLab autoalojado debe comprobar que tiene 19.4.2, 19.3.5, 19.2.8 o posterior y, si usa imágenes propias, verificar que incluyen el Ruby corregido.
- Conviene revisar los registros de CI/CD y las caídas de procesos de trabajo de los últimos días en busca de configuraciones con expresiones regulares anómalas.
BleepingComputer ha informado además de que la agencia estadounidense CISA considera este fallo explotado activamente. No es la primera vez que una instancia de GitLab se convierte en objetivo: opensecurity ya contó cómo Red Hat investigó un acceso no autorizado a un GitLab de su división de consultoría.
Preguntas frecuentes
¿Qué le ha pasado al GitLab de Alpine Linux?
Un atacante intentó explotar CVE-2026-97229 los días 20 y 21 de octubre y provocó caídas en el servidor. Alpine no ha encontrado pruebas de ejecución de código, pero ha reconstruido la instancia desde cero.
¿Están comprometidos los paquetes de Alpine?
Según el proyecto, no hay pruebas de manipulación en commits, paquetes ni versiones, y las claves de firma no estaban en el servidor de GitLab.
¿Qué es CVE-2026-97229?
Un desbordamiento de entero en Onigmo, el motor de expresiones regulares de Ruby usado por GitLab, que permite ejecutar código con una configuración de CI/CD manipulada. Tiene CVSS 10.
¿Qué versiones de GitLab corrigen el fallo?
Las 19.4.2, 19.3.5 y 19.2.8 o posteriores. En imágenes propias hay que comprobar además que incluyan el parche de Ruby.
Fuentes:
