Incidente de seguridad de GitLab: intento de explotación de CVE-2026-97229

Artículo original ↗ Discusión en Hacker News ↗

Un incidente de seguridad que afecta a GitLab en Alpine Linux pone de relieve cómo una vulnerabilidad crítica en realidad provenía del motor de expresiones regulares de Ruby y no del código de GitLab. Quienes comentan argumentan que esto expone problemas sistémicos con depender de compilaciones personalizadas, dependencias fijadas y bibliotecas en C, y muestra cómo el escaneo tradicional basado en CVE puede pasar por alto problemas cuando los componentes upstream corrigen en silencio. El debate se amplía a si herramientas autoalojadas complejas como GitLab deberían estar directamente en Internet pública, los límites de SaaS y de las garantías de residencia de datos, y la necesidad de un parcheo más automatizado y continuo, además de lenguajes más seguros para software expuesto a la red.

Naturaleza de la vulnerabilidad y problemas de cadena de suministro

  • El problema de GitLab proviene de fallos en el motor de regexp de Ruby, no del propio código de GitLab.
  • Los paquetes oficiales de GitLab incluyen Ruby con un parche fuera del árbol; la imagen de GitLab de Alpine usaba Ruby “normal” y siguió siendo vulnerable incluso después de actualizar GitLab.
  • Como Ruby no solicitó CVE para sus correcciones, los escáneres de vulnerabilidades que se basan en versiones de GitLab (o en CVE de Ruby) considerarían erróneamente seguras algunas imágenes.

Prácticas de actualización, dependencias y compilación

  • Construir imágenes por cuenta propia y fijar dependencias crea “cachés locales” que deben mantenerse de forma activa; de lo contrario, se pierden correcciones críticas.
  • Muchos ecosistemas (Ruby, PHP, Python, JS, Lua, etc.) ven actualizaciones lentas del runtime porque las versiones quedan fuertemente fijadas en las aplicaciones.
  • Quienes comentan sostienen que los reconstruidos automáticos casi constantes, el seguimiento de dependencias y las actualizaciones continuas se están volviendo inevitables.

Exposición: VPN, Zero Trust y servicios públicos

  • Varios argumentan que las herramientas autoalojadas deberían vivir detrás de VPNs o proxies con conocimiento de identidad; solo las organizaciones con equipos de seguridad reales deberían exponerlas públicamente.
  • Otros señalan que “zero trust” no significa “accesible públicamente”, sino un control de acceso sólido en el borde de la aplicación.
  • Se plantea si este tipo de exploit podría ocurrir dentro de una VPN; la implicación es que sí, si el servicio vulnerable es alcanzable.

SaaS frente a autoalojamiento y preocupaciones de datos en la UE

  • Hay debate sobre si las empresas de la UE pueden alojar legalmente datos sensibles con proveedores SaaS no europeos (por ejemplo, debido al RGPD y a la CLOUD Act).
  • Algunos dicen que los proveedores SaaS ofrecen opciones de residencia de datos en la UE; otros desconfían de las afirmaciones sobre soberanía de datos y el entrenamiento de IA con datos de clientes.
  • “Vibe-coding” de reemplazos internos para SaaS se ve como atractivo en coste, pero arriesgado si nadie asume la seguridad y el mantenimiento a largo plazo.

Lenguajes, seguridad de memoria y regex desde entrada no confiable

  • Frustración con los fallos recurrentes de bibliotecas C (desbordamientos enteros, dobles liberaciones) y llamados a mover el código de cara a la red fuera de C.
  • Contraargumentos: reescribir todo no es realista; incluso las reescrituras en Rust (por ejemplo, análogos de sudo/coreutils) tienen errores.
  • Los lenguajes con seguridad de memoria como Rust no pueden detener todos los fallos lógicos (por ejemplo, explosiones de regex, envolturas de enteros), pero ayudan a evitar los vectores típicos de RCE.
  • Algunos insisten en que compilar regex a partir de entrada no confiable es intrínsecamente peligroso; otros cuestionan hasta dónde llega ese argumento.

Contenedores, etiquetas y escaneo

  • Alpine volvió a publicar la imagen 19.3.6 con Ruby actualizado; algunos sostienen que deberían haber cambiado la etiqueta, otros dicen que las etiquetas denotan la versión de la aplicación, no la inmutabilidad de la imagen.
  • Recomendación: fijar imágenes por digest (SHA) y usar herramientas (por ejemplo, Renovate) para seguir los cambios.
  • Un aspecto “desagradable”: los escáneres basados en versiones clasifican erróneamente la imagen vulnerable como corregida porque la versión de GitLab ya supera el umbral parcheado, mientras que el parche oculto de Ruby no tiene un CVE.

Alternativas a GitLab e respuesta a incidentes

  • Se sugieren forjas más simples como Forgejo o Gitea para reducir la superficie de ataque; otros señalan que también acumulan CVE, solo que hasta ahora menos que GitLab.
  • Algunos creen que las grandes pilas de código abierto ampliamente usadas podrían endurecerse sistemáticamente con suficiente financiación y herramientas avanzadas (incluida la IA).
  • Se elogia el postmortem transparente de Alpine y su respuesta conservadora (tratar la “falta de evidencia” como no suficiente prueba de seguridad) como comportamiento responsable.