GitLab CVE-2026-97229: Alpine informa de un intento de explotación

Alpine Linux dice que un atacante intentó explotar CVE-2026-97229 en el servidor GitLab del proyecto los días 20 y 21 de octubre de 2026. Fue aproximadamente una semana después de que GitLab publicara una corrección. La lección más importante está en el informe del incidente de Alpine, publicado el 28 de octubre. Actualizar GitLab en sí no cerró el agujero en la configuración de Alpine, porque la corrección real es un parche de Ruby.

Alpine es una distribución Linux pequeña y muy popular como base para contenedores Docker. Sus desarrolladores usan un servidor GitLab autoalojado para gestionar el código de sus paquetes.

Qué pasó en el servidor de Alpine

Según Alpine, los intentos hicieron caer los procesos worker de GitLab ocho veces. En cuatro de esas caídas, el atacante llegó a completar parte del exploit.

Alpine dice que no encontró pruebas de que el ataque funcionara. «No hemos encontrado pruebas de que tuviera éxito, pero no podemos descartarlo», dice la publicación.

Así que el equipo trató el servidor como comprometido. Reconstruyó GitLab desde cero y limitó el acceso a desarrolladores y servidores de compilación. También restableció todas las contraseñas y claves secretas.

El proyecto también revisó lo que más importa a sus usuarios. Según Alpine, su repositorio aports, sus paquetes y sus versiones estables del 21 de octubre se compararon con registros externos. No mostraron señales de manipulación. Esas versiones fueron Alpine 3.21.9, 3.22.7, 3.23.7 y 3.24.3. Las claves que firman los paquetes de Alpine nunca se guardaron en el servidor GitLab, y se revisaron 45 máquinas de compilación.

Alpine encontró un problema más por el camino. Los inicios de sesión automatizados en su servidor usaban contraseñas filtradas de otros sitios web. Quien haya reutilizado su contraseña de Alpine GitLab en otro lugar debería cambiarla allí.

Por qué la actualización de GitLab no ayudó

Esta es la parte que otros administradores de servidores autoalojados deberían leer dos veces. «Actualizar a GitLab 19.3.6 el 22 de octubre no corrigió la vulnerabilidad», escribe Alpine.

La razón está en cómo distribuye GitLab la corrección. Los paquetes oficiales de GitLab incluyen su propia copia de Ruby, el lenguaje de programación en el que está escrito GitLab. Según Alpine, la corrección de CVE-2026-97229 es un conjunto de parches para ese Ruby incluido. Alpine ejecuta GitLab sobre Ruby estándar, así que una versión más reciente de GitLab por sí sola no cambió nada.

Alpine también dice que se saltó por error la actualización 19.3.5 el 13 de octubre. Durante el ataque todavía ejecutaba 19.3.4. Sus propios paquetes ruby ya incluyen la corrección, y los usuarios de Alpine deberían ejecutar apk upgrade.

Qué es CVE-2026-97229

GitLab reveló el fallo el 12 de octubre de 2026 e instó a todas las instalaciones autogestionadas a actualizar. BleepingComputer informó de que se trata de un desbordamiento de enteros en la parte de GitLab que lee expresiones regulares en los archivos de pipelines de CI/CD. Las expresiones regulares son patrones de texto, y los pipelines de CI/CD son los scripts que compilan y prueban código automáticamente. El aviso de GitLab decía que el error «podría haber permitido a un usuario no autenticado ejecutar código arbitrario en el servidor GitLab».

Un investigador con el alias «joaxcar» lo reportó a través del programa de recompensas por errores de GitLab en HackerOne. GitLab.com ya estaba parcheado, y los clientes de GitLab Dedicated no tenían que hacer nada.

Elemento	Detalle
Gravedad	CVSS 10.0, el máximo
Tipo de error	Desbordamiento de enteros en el compilador de regex de CI/CD
Versiones corregidas	19.2.8, 19.3.4 o 19.3.5, y 19.4.2 (las fuentes difieren sobre 19.3)
Exploit público	Publicado por Rapid7 el 13 de octubre
Hosts expuestos	25.766 con versiones vulnerables, según Censys

Las fuentes no coinciden sobre la corrección de 19.3. BleepingComputer indica 19.3.4. Daily Security Review y Alpine apuntan ambos a 19.3.5. Consulte el aviso del propio GitLab para su rama exacta.

Daily Security Review informó el 14 de octubre de que el exploit depende de un archivo manipulado enviado mediante commit a una rama de un proyecto público. En ese momento no había ningún ataque confirmado en la práctica. La Agencia de Ciberseguridad y Seguridad de Infraestructuras de EE. UU. (CISA) tampoco había añadido el error a su lista de fallos explotados. Censys también detectó que alrededor del 31 % de los hosts GitLab que encontró seguían sin parchear.

Este es el segundo fallo de regex de gravedad máxima de GitLab este mes. GitLab 19.5.1 corrigió CVE-2026-110264, un error distinto con CVSS 10.0, el 21 de octubre.

Qué significa esto para los desarrolladores

El informe de Alpine convierte un parche conocido en una lista de comprobación práctica. También muestra que «hemos actualizado» y «estamos seguros» no son lo mismo.

• Compruebe de dónde obtiene Ruby su GitLab. Si ejecuta GitLab desde el código fuente o desde paquetes de la distribución sobre el Ruby del sistema, la actualización de GitLab por sí sola podría no incluir la corrección. Confirme que su Ruby incluye los parches, como tuvo que hacer Alpine.
• No se salte las versiones de corrección. Alpine pasó por alto la 19.3.5 por error. Vincule su proceso de actualización a los avisos de seguridad de GitLab, no a un calendario rutinario.
• Asuma que un servidor público fue sondeado. Existe un exploit público desde el 13 de octubre. Si ejecutó una versión vulnerable en internet después de esa fecha, revise los registros de caídas de los workers de las semanas siguientes.
• Restrinja los proyectos públicos. El exploit necesita un archivo manipulado en un proyecto público. Hasta que aplique el parche, limite quién puede llegar al servidor y desactive la creación de proyectos públicos para usuarios que no sean de confianza.
• Mantenga las claves de firma fuera de la plataforma de código. Alpine pudo afirmar que sus paquetes estaban a salvo porque las claves de firma nunca estuvieron en GitLab. Vale la pena copiar esa decisión de diseño.
• Restablezca las contraseñas reutilizadas. En Alpine también aparecieron inicios de sesión por relleno de credenciales (credential stuffing). Anime a los usuarios a usar contraseñas únicas y el inicio de sesión en dos pasos hasta que estén implantados en todas partes.