Alpine Linux reconstruyó desde cero su instancia de GitLab después de detectar intentos de explotar la vulnerabilidad crítica CVE-2026-97229. El proyecto no encontró pruebas de que el atacante ejecutara código o modificara paquetes y lanzamientos, pero tampoco pudo descartar por completo una intrusión. Por eso trató el servidor como comprometido y aplicó una recuperación conservadora.
Qué ocurrió en GitLab de Alpine
Según el aviso oficial de Alpine, el ataque ocurrió entre el 20 y el 21 de octubre de 2026. Una cuenta recién creada envió configuraciones de CI especialmente preparadas contra una vulnerabilidad del compilador de expresiones regulares usado por GitLab. El problema está relacionado con Onigmo, el motor incluido en Ruby, y recibió una puntuación CVSS de 10,0.
Los intentos provocaron ocho caídas de procesos trabajadores de GitLab. En cuatro ocasiones el atacante avanzó parcialmente en la explotación, pero Alpine no observó indicios de ejecución de código en el servidor. El atacante también descargó la imagen de contenedor de GitLab, un dato que sugiere que estaba estudiando la configuración concreta del objetivo.
Por qué Alpine reconstruyó el servidor
Actualizar GitLab no bastó en la instalación afectada. Alpine explica que instaló primero una versión que no incluía la corrección adecuada y que una actualización posterior tampoco solucionó el problema porque el parche estaba en el Ruby distribuido por los paquetes oficiales de GitLab. Su imagen personalizada utilizaba un Ruby estándar sin ese parche.
La respuesta fue cerrar el servicio, reconstruirlo desde cero, cambiar las claves secretas y restablecer contraseñas, tokens y la autenticación de dos factores. Al reabrir el servicio, GitLab funcionaba con la versión 19.3.7 y Ruby 3.3.13. Alpine también recomendó reemplazar credenciales que pudieran haberse reutilizado en otros sitios.
¿Se alteraron los paquetes de Alpine?
Hasta la revisión publicada por el proyecto, no se encontraron modificaciones en el repositorio aports, los paquetes ni los lanzamientos de octubre analizados. Las claves de firma de paquetes y lanzamientos tampoco estaban almacenadas en el servidor GitLab. Esto reduce el riesgo de una alteración de la cadena de suministro, pero no equivale a demostrar que nunca hubo acceso: faltaban algunos registros y no existía telemetría completa de conexiones salientes.
La diferencia es importante. “No se encontró evidencia” no significa “se confirmó que era imposible”. Una noticia responsable debe mantener ambas partes del comunicado.
Qué deben revisar los administradores
- Si administras GitLab con una imagen propia, verifica tanto la versión de GitLab como la versión de Ruby que incorpora la corrección.
- Si utilizas la imagen
alpinelinux/gitlab, sigue las instrucciones oficiales y vuelve a descargar una imagen corregida; no confíes solo en que el número de GitLab haya cambiado. - Rota contraseñas, tokens, secretos de CI/CD, credenciales de webhooks y claves de integraciones si pudieron estar en la instancia afectada.
- Comprueba las firmas, hashes y procedencia de las imágenes antes de desplegarlas en producción.
Qué significa para usuarios de Perú y Latinoamérica
La noticia afecta sobre todo a administradores de servidores, equipos DevOps y proyectos que utilizaban el GitLab de Alpine. No significa que una computadora personal con Alpine esté infectada ni que todas las imágenes Alpine sean inseguras. Los usuarios de la región deben actualizar mediante los repositorios oficiales y consultar los avisos de Alpine, especialmente si mantienen servidores, runners de CI o imágenes de contenedor propias.
No hay un precio o trámite local asociado: Alpine y sus paquetes se distribuyen por Internet. El coste real para una empresa es operativo: revisar imágenes, rotar secretos y repetir despliegues. En conexiones lentas, conviene planificar la descarga y conservar una copia verificada de la imagen anterior solo para una reversión controlada.
Conclusión
El incidente muestra por qué una actualización de la aplicación no siempre corrige una vulnerabilidad de una dependencia incluida. Alpine no confirmó una alteración de sus paquetes, pero reconstruyó GitLab porque no podía descartar una ejecución remota. Esa es la distinción que administradores y lectores deben conservar.
Enlaces internos: CVE-2026-98432: fallo crítico del kernel Linux · Time4Popcorn: un actualizador inseguro expuso millones de PC
Fuentes: comunicado oficial de Alpine sobre CVE-2026-97229 · instrucciones oficiales tras la reapertura · análisis de BleepingComputer.
No hay comentarios.:
Publicar un comentario