> ## Content Index
> Fetch the complete content index at: https://fomoera.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Alpine Linux reconstruye su servidor de GitLab tras un intento de explotar una falla crítica
- URL: https://fomoera.com/alpine-linux-gitlab-falla-ruby/
- Published: 2026-10-31T09:40:00.000Z
- Updated: 2026-10-31T09:40:00.000Z
- Description: El servicio ya volvió a funcionar. Alpine no halló pruebas de ejecución de código, pero no pudo descartarla y restableció las cuentas.
- Author: Patricia Rodriguez
- Tags: Tecnología y Ciencia, Ciberseguridad

Alpine Linux reabrió el servidor de GitLab que utiliza para desarrollar su distribución después de reconstruirlo por un intento de explotar una vulnerabilidad crítica. El proyecto afirma que no encontró pruebas de que el atacante ejecutara código en el servidor, aunque tampoco pudo descartarlo.

La falla, identificada como CVE-2026-97229, recibió una puntuación de gravedad de 10 sobre 10\. GitLab explicó que, bajo ciertas condiciones, podía permitir a una persona sin autenticar ejecutar código en un servidor mediante una configuración de integración continua especialmente preparada. La empresa publicó una corrección el 12 de octubre.

Según Alpine, una cuenta recién registrada envió configuraciones maliciosas a su instancia el 20 y el 21 de octubre. Los intentos provocaron ocho caídas de procesos de GitLab; en cuatro, el atacante avanzó parcialmente antes de fallar en el siguiente paso.

## Por qué la actualización no bastó

Alpine reconoció que el 13 de octubre había instalado por error GitLab 19.3.4 en lugar de la versión 19.3.5, que incluía la corrección para esa rama. Cuando actualizó de nuevo, el 22 de octubre, a la versión 19.3.6, su servidor siguió siendo vulnerable por otro motivo: la imagen que utilizaba incorporaba su propia versión de Ruby.

El problema estaba en Onigmo, el motor de expresiones regulares de Ruby. GitLab había aplicado el parche al Ruby que distribuye en sus paquetes e imágenes oficiales, pero esa corrección no se trasladó automáticamente al Ruby separado que usaba Alpine.

El proyecto Ruby publicó el 23 de octubre las versiones 3.3.13, 3.4.12 y 4.0.9 con correcciones para varias fallas relacionadas. Para las instalaciones que usan Ruby por separado, Alpine advierte que actualizar GitLab no basta: también deben comprobar que su versión de Ruby incluya el parche. Ruby recomienda esas versiones o posteriores de sus respectivas ramas.

## Qué pudo comprobar Alpine

El proyecto decidió tratar el servidor como potencialmente comprometido y reconstruirlo desde cero. Parte de los registros del día del ataque ya no estaba disponible y Alpine no registraba las conexiones salientes, lo que limitó su capacidad para determinar si se había ejecutado código.

Alpine informó que sus comprobaciones no encontraron alteraciones en el repositorio aports, los paquetes creados entre el 20 y el 24 de octubre ni las versiones estables de Alpine publicadas el 21 de octubre. El proyecto señaló que estaba ampliando la revisión hasta el 27 de octubre, cuando cerró el servicio para iniciar la reconstrucción.

El servidor ya funciona con GitLab 19.3.7 y Ruby 3.3.13\. Alpine restableció las contraseñas y borró la configuración anterior de autenticación en dos pasos de todas las cuentas, por lo que cada usuario debe configurarla de nuevo. También indicó que los usuarios y responsables de proyectos deberán volver a configurar algunos tokens y secretos; recomendó reemplazar las credenciales que podrían haber quedado expuestas.

El 29 de octubre, la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos, CISA, incorporó la falla a su catálogo de vulnerabilidades que se sabe que han sido explotadas. La agencia fijó el 1 de noviembre como fecha límite para que las agencias federales estadounidenses apliquen las medidas correspondientes. Esa inclusión no confirma que el intento contra Alpine lograra ejecutar código.

Como respuesta al incidente, Alpine anunció que aplicará las actualizaciones críticas de GitLab en el plazo de un día, registrará las conexiones salientes y conservará los registros durante más de 14 días. También prevé firmar las etiquetas de sus lanzamientos para que puedan verificarse de forma independiente de GitLab.

*Fuentes:* [1](https://alpinelinux.org/posts/GitLab-security-incident-CVE-2026-97229.html?ref=fomoera.com), [2](https://alpinelinux.org/posts/GitLab-reopened-after-security-incident.html?ref=fomoera.com), [3](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/?ref=fomoera.com), [4](https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/?ref=fomoera.com), [5](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field%5Fcve=CVE-2026-97229&ref=fomoera.com)