GitLab: Alpine Linux reconstruye su instancia tras ataque

Alpine Linux dio por comprometido su GitLab y lo reconstruyó desde cero

El 20 y 21 de octubre, una cuenta recién registrada envió configuraciones de CI manipuladas al GitLab de Alpine Linux y tumbó los procesos worker de la instancia ocho veces. En cuatro de esos crashes el atacante llegó a mitad del exploit y falló en el paso siguiente. La distribución no encontró evidencia de que el ataque haya funcionado, pero tampoco pudo descartarlo: trató la instancia como comprometida y la reconstruyó desde cero.

Para cualquier founder que corre su propio GitLab, la lección no es solo actualizar más rápido. Es que el parche que Alpine aplicó no arreglaba la vulnerabilidad, y eso es un problema de arquitectura de la cadena de suministro, no de disciplina operativa.

Qué es CVE-2026-97229 y por qué tiene CVSS 10.0

CVE-2026-97229 es una vulnerabilidad de desbordamiento de enteros en el compilador de expresiones regulares del CI/CD de GitLab, y afecta tanto a Community Edition como a Enterprise Edition. GitLab le asignó un CVSS de 10.0, el máximo posible: se explota de forma remota, con baja complejidad y sin privilegios ni interacción del usuario, según el análisis de Help Net Security.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El bug de fondo no está en el código de GitLab, sino en Onigmo, el motor de expresiones regulares integrado en Ruby. Según The Hacker News, Ruby publicó las versiones 4.0.9, 3.4.12 y 3.3.13 para corregir tres fallos de Onigmo que están detrás de cuatro vulnerabilidades críticas de GitLab.

GitLab publicó las versiones corregidas el 12 de octubre (19.4.2, 19.3.5 y 19.2.8). El detalle que lo cambia todo: ese fix es un conjunto de parches al Ruby que GitLab empaqueta en sus propios paquetes e imágenes de contenedor. El Ruby upstream recién publicó la corrección el 23 de octubre.

Por qué actualizar GitLab no fue suficiente

Alpine corría GitLab 19.3.4, sin el fix del 12 de octubre. El 22 de octubre subió a 19.3.6 y el 26 descubrió que la instancia seguía vulnerable. La razón: su imagen usaba Ruby estándar, no el Ruby parcheado que GitLab distribuye en sus paquetes oficiales.

Ese es el punto que debería encender alarmas en cualquier equipo de plataforma:

Si corres GitLab con tu propio Ruby (desde código fuente o en tu propia imagen de contenedor), actualizar GitLab no alcanza. Necesitas Ruby 3.3.13, 3.4.12, 4.0.9 o superior.
Si usas la imagen alpinelinux/gitlab, hay que volver a hacer pull de alpinelinux/gitlab:19.3.6: la imagen publicada el 27 de octubre incluye Ruby 3.3.13. Cualquier imagen 19.3.6 descargada antes de esa fecha, y todos los tags anteriores, siguen vulnerables.

The Hacker News agrega un detalle que complica el escaneo: Ruby no solicitó identificadores CVE propios para estos arreglos, al menos por ahora, y pidió seguir los cuatro CVE de GitLab. Como los registros CVE de GitLab nombran solo a GitLab como producto afectado, un escáner que cruce esos registros contra la versión de Ruby instalada no tiene con qué hacer match.

¿Qué datos podrían haberse expuesto?

Alpine listó lo que un exploit exitoso habría dejado al alcance del atacante: direcciones de email, nombres e IPs de todos los usuarios, hashes de contraseñas, secretos de 2FA, variables de CI/CD y tokens de runners, credenciales de webhooks, integraciones y push mirrors, tokens de acceso personal (guardados como hashes), repositorios privados e issues y merge requests confidenciales.

Lo que sí quedó descartado: las claves de firma de paquetes y releases de Alpine nunca estuvieron almacenadas en el servidor de GitLab. Y las verificaciones del 24 de octubre sobre aports, paquetes y los releases del 21 de octubre (3.21.9, 3.22.7, 3.23.7, 3.24.3) no mostraron manipulación.

La incertidumbre viene de tres huecos concretos: un exploit exitoso no deja crash ni rastro en los logs web; parte de los logs del día del ataque se perdió (logs de jobs en background y el filesystem del contenedor viejo); y no había logging de conexiones salientes, ni el proveedor de hosting las guarda.

El patrón: cuatro RCE en un mes

Según GCN, CVE-2026-97229 no es un caso aislado. Es la cuarta falla de ejecución de código en el motor de expresiones regulares de GitLab reportada en un mes por el mismo investigador, que usa el handle joaxcar, a través del programa de bug bounty. Las dos primeras, divulgadas el 23 de septiembre, requerían una cuenta autenticada y se calificaron 9.9. Las dos de octubre, CVE-2026-97229 y CVE-2026-110264, no requieren cuenta y se calificaron 10.0.

CVE-2026-110264, parcheada el 21 de octubre, alcanza todas las versiones de GitLab desde la 7.0, lanzada en 2014, y no tiene workaround: la única salida es actualizar. GitLab publicó el fix para siete líneas de release a la vez (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13).

Para dimensionar el riesgo: Rapid7 reprodujo ejecución arbitraria de código sobre una imagen oficial de GitLab CE 19.4.1 sin parchear, mientras que el mismo input no funcionó contra la 19.4.2 corregida. El requisito era poder hacer commit de un .gitlab-ci.yml malicioso y una ruta de repositorio con caracteres UTF-8 a una rama de un proyecto público, algo que una cuenta común puede lograr en instancias self-managed que permiten crear proyectos públicos.

¿Qué significa esto para tu startup?

Si tu equipo corre GitLab self-managed, este incidente te toca de tres formas distintas.

1. Audita tu Ruby, no solo tu GitLab. Revisa si tu instancia usa el Ruby empaquetado por GitLab o uno propio. Si es propio, verifica la versión y actualiza a 3.3.13, 3.4.12 o 4.0.9+. Si usas la imagen de Alpine, vuelve a hacer pull del tag 19.3.6.

2. Rota credenciales que vivan en CI/CD. Alpine reseteó todas las contraseñas y reemplazó las claves secretas de su GitLab. La lista de lo expuesto —variables de CI/CD, tokens de runner, credenciales de webhooks y push mirrors— es exactamente el tipo de secreto que las startups acumulan sin inventariar. Haz la lista de qué secretos pasan por tus pipelines y rota los que no puedas justificar.

3. Cierra la brecha de logging. Alpine no registraba conexiones salientes y su proveedor tampoco. Sin ese registro, la ausencia de evidencia no es evidencia de ausencia. Activa logging de conexiones salientes y extiende la retención más allá de los 14 días que Alpine tenía.

Y una acción de higiene que aplica incluso si no usas GitLab: si compilas expresiones regulares a partir de input que controla un usuario, estás expuesto al mismo bug de Onigmo. The Hacker News recuerda que el aviso de Ruby señala como afectadas a las aplicaciones que pasan strings controlados por atacantes a Regexp.new, Regexp.union o Regexp.compile, o que interpolan input dentro de un patrón. Dos defensas que parecen servir no sirven: fijar Regexp.timeout no detiene estos bugs, y limitar el largo del patrón es poco confiable porque patrones cortos también los disparan.

Conclusión

Alpine hizo lo correcto: ante la duda, reconstruyó. El costo es alto —su GitLab estuvo cerrado, con todas las contraseñas reseteadas y las claves secretas reemplazadas— pero es la única respuesta honesta cuando no puedes probar que no hubo ejecución de código.

Lo que este caso deja al descubierto es más incómodo: actualizar la aplicación no siempre actualiza la dependencia que tiene el bug. Alpine subió de 19.3.4 a 19.3.6 y siguió vulnerable porque el fix vivía en un Ruby que su build nunca aplicó. Si tu equipo mide seguridad por tener la versión de GitLab al día, esa métrica te está mintiendo.