Los atacantes ya están explotando CVE-2026-97229, una vulnerabilidad crítica que puede permitir ejecutar código en servidores GitLab. La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA) confirmó la explotación activa el 29 de octubre y añadió el fallo a su catálogo de vulnerabilidades conocidas y explotadas.
El problema está en el compilador de expresiones regulares utilizado para procesar configuraciones de CI/CD. GitLab publicó correcciones el 12 de octubre, pero el caso de Alpine Linux muestra que tener un intento de ataque no equivale a confirmar una intrusión: la organización encontró señales preocupantes en su instancia, aunque no pudo determinar si el atacante llegó a ejecutar código.
Qué permite el fallo y qué versiones están corregidas
Identificado como CVE-2026-97229, el fallo deriva de un desbordamiento de enteros en el compilador de expresiones regulares de CI/CD. Una expresión especialmente preparada dentro de una configuración de pipeline puede, bajo ciertas condiciones, sortear la validación y conducir a la ejecución de código arbitrario en el servidor. GitLab describió el problema como una posible ejecución por parte de un usuario no autenticado.
Rapid7, que reprodujo la vulnerabilidad, precisa una condición relevante para esa ruta: el atacante necesita poder introducir una configuración CI/CD maliciosa en un repositorio antes de activar el fallo. En una instancia autogestionada que permita a nuevos usuarios registrarse y crear proyectos públicos, esa posibilidad puede estar al alcance de una cuenta ordinaria. Rapid7 confirmó la cadena en la imagen oficial de GitLab CE 19.4.1 y dice que la misma entrada no ejecutó código en la imagen corregida 19.4.2.
GitLab lanzó las versiones 19.4.2, 19.3.5 y 19.2.8 para Community Edition y Enterprise Edition. Son las versiones corregidas para sus respectivas ramas: las instalaciones autogestionadas que ejecuten versiones anteriores dentro de esas ramas deben actualizarse. GitLab.com ya está parcheado y los clientes de GitLab Dedicated no necesitan actuar, según Rapid7 y la documentación de GitLab.
CISA ordenó a las agencias federales estadounidenses proteger sus servidores antes del domingo, conforme a la directiva BOD 26-04. Aunque ese plazo se aplica a organismos federales, la agencia recomendó también a los equipos del sector privado priorizar la actualización. GitLab publicó además detecciones de amenazas para clientes con instancias autogestionadas.
Alpine detectó intentos y reconstruyó su instancia
Alpine Linux informó que un atacante probó la vulnerabilidad contra su servidor GitLab el 20 y el 21 de octubre, después de que GitLab publicara el parche. La instancia de Alpine todavía usaba GitLab 19.3.4. Según su análisis, una cuenta recién registrada envió configuraciones CI/CD manipuladas que provocaron ocho caídas de procesos de trabajo; en cuatro de ellas, el atacante avanzó parcialmente con el exploit, pero no completó el siguiente paso.
El atacante también descargó la imagen de contenedor de GitLab de Alpine, un indicio de que podía estar ajustando el exploit para esa compilación concreta. Alpine dijo que no encontró pruebas de que se ejecutara código, pero tampoco pudo descartarlo. Como los registros disponibles no permitían cerrar esa posibilidad, trató el servidor como comprometido y lo reconstruyó desde cero.
La organización verificó que el repositorio aports, los paquetes y los lanzamientos del 21 de octubre no habían sido alterados. También señaló que las claves de firma de paquetes y lanzamientos no estaban almacenadas en el servidor GitLab. Su instancia volvió a abrir el 29 de octubre con GitLab 19.3.7, después del cierre y la reconstrucción.
El incidente expuso otro matiz técnico: Alpine explicó que actualizar GitLab no bastó en su caso. La corrección también depende de un parche a Ruby incluido por GitLab en sus paquetes oficiales; la imagen de Alpine utilizaba una versión estándar de Ruby que no lo incorporaba. La organización indicó que quienes desplieguen GitLab con Ruby propio deben actualizar también Ruby a una versión corregida: 3.3.13, 3.4.12 o 4.0.9, o posterior.
Durante el cierre, Alpine restableció las contraseñas y reemplazó las claves secretas de GitLab. También anunció que aplicará los parches críticos de GitLab en un día, revisará si cada lanzamiento requiere actualizar Ruby u otros componentes y ampliará el registro de conexiones salientes y de base de datos. Para las instancias autogestionadas que aún no puedan actualizar, Rapid7 menciona como medidas temporales restringir el acceso anónimo a proyectos públicos y evitar que usuarios no confiables creen o modifiquen proyectos públicos; esas medidas reducen la exposición a la ruta demostrada, pero no corrigen el compilador vulnerable.
Fuentes: BleepingComputer, Rapid7, Alpine Linux, GitLab Docs
