Lanzamientos de la CLI de OVHcloud secuestrados para robar secretos mediante el compromiso de una cuenta de GitHub

El lunes 19 de octubre, los atacantes comprometieron la cuenta de GitHub de un colaborador y reemplazaron los archivos de descarga de cinco lanzamientos existentes de la interfaz de línea de comandos (CLI) de OVHcloud. Los binarios maliciosos, diseñados para robar secretos de los discos locales, estuvieron disponibles en GitHub durante 94 minutos antes de que el proveedor de nube los eliminara y emitiera un lanzamiento limpio e inmutable.

Qué sucedió

El incidente afectó las versiones v0.11.0 a v0.15.0 de la CLI de OVHcloud, publicadas entre el 14 de abril y el 16 de septiembre. Entre las 12:47 y las 14:21 UTC, un atacante con acceso a una cuenta de colaborador eliminó los archivos originales del archivo y subió nuevos que contenían malware. El atacante también reemplazó el archivo checksums.txt para asegurar que los hashes publicados coincidieran con los binarios maliciosos, evadiendo las comprobaciones básicas de integridad que dependen únicamente de esos hashes proporcionados.

Octave Klaba, fundador de OVHcloud, confirmó que el código fuente, las etiquetas de lanzamiento y las tuberías internas de compilación permanecieron intactas. Los archivos maliciosos eran simples compilaciones de Go de un commit posterior, subidas directamente a las páginas de lanzamiento de GitHub. La empresa respondió eliminando los archivos intercambiados y publicando la versión v0.16.0 como un lanzamiento inmutable, una función de GitHub que impide modificaciones posteriores en los activos del lanzamiento. El colaborador comprometido había fusionado trabajo en el repositorio de documentación, pero no era un miembro público de la organización.

Cómo funciona

El ataque explotó la capacidad de los usuarios con permisos de escritura para modificar lanzamientos existentes en GitHub cuando la inmutabilidad no está habilitada. Esta configuración, disponible generalmente desde octubre de 2025, bloquea los archivos y etiquetas de los lanzamientos, pero solo protege los creados después de su activación. OVHcloud no había habilitado esta opción para los lanzamientos afectados, lo que permitió al atacante intercambiar los binarios sin activar ninguna comprobación de la tubería CI/CD ni ejecuciones de flujo de trabajo.

El malware en sí era un ladrón de secretos dirigido a credenciales almacenadas en el disco, como las de ~/.ovh.conf o variables de entorno. Investigadores de OpenSourceMalware vincularon la cuenta comprometida con GlassWorm, una campaña conocida por ocultar código en caracteres Unicode invisibles. Aunque no se ha analizado públicamente ninguna copia del binario de octubre, cuatro repositorios personales asociados con la cuenta mostraron force-pushes en marzo que contenían cargadores consistentes con las tácticas de GlassWorm.

Detalles clave

• Versiones comprometidas: Se consideran comprometidas v0.11.0, v0.12.0, v0.13.0, v0.14.0 y v0.15.0; v0.10.0 está limpia.
• Plataformas afectadas: macOS (x86_64, arm64), Linux (x86_64, arm64) y Windows (x86_64). Las compilaciones de Linux i386, Windows i386, Windows arm64 y WebAssembly no fueron tocadas.
• Ventana de exposición: De 12:47 a 14:21 UTC el 19 de octubre de 2026.
• Método de detección: Los binarios maliciosos muestran una pseudo-versión como v0.15.1-0.20261013083505-5ead8ef9b43d+dirty y contienen -ldflags="-s -w", mientras que los lanzamientos genuinos muestran números de etiqueta y ninguna línea ldflags.
• Rutas de instalación seguras: Los usuarios de Homebrew estaban protegidos porque los casks fijaban los hashes SHA-256 originales, haciendo que las descargas desajustadas fallaran. Las imágenes de Docker y los métodos go install tampoco se vieron afectados.
• Hash malicioso: El SHA-256 para el archivo v0.15.0 de Linux arm64 intercambiado es 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb.

Por qué importa

Este incidente destaca la fragilidad de la seguridad de la cadena de suministro cuando no se aplica la inmutabilidad de los lanzamientos. Muchos desarrolladores confían en scripts de instalación o descargas directas de los lanzamientos de GitHub sin verificar firmas criptográficas ni fijar hashes. Por ejemplo, el script oficial de instalación de OVHcloud descarga el último archivo sin comprobar un hash, lo que hace vulnerable a cualquier usuario que lo haya ejecutado durante la ventana de 94 minutos. Del mismo modo, los trabajos de CI que obtienen archivos sin hashes fijados habrían instalado silenciosamente la versión maliciosa.

Para los equipos de ingeniería, esto sirve como un recordatorio crítico de que la confianza en los colaboradores de un repositorio debe equilibrarse con salvaguardias técnicas. Incluso si una tubería de compilación es segura, la manipulación directa de los activos del lanzamiento puede evitarla por completo. El hecho de que los usuarios de Homebrew estuvieran protegidos demuestra el valor de los gestores de paquetes que aplican el fijado de hashes, mientras que aquellos que usaban instalaciones manuales o scripts personalizados enfrentaron un riesgo mayor. Rotar los secretos es ahora obligatorio para cualquiera que pueda haber ejecutado el binario comprometido, ya que el malware probablemente exfiltró todos los secretos legibles de la máquina anfitriona.

Lo que puedes hacer

• Rota cada secreto almacenado en máquinas que puedan haber ejecutado la CLI comprometida, utilizando una máquina diferente y limpia para realizar la rotación.
• Elimina el binario actual de la CLI de OVHcloud e instala la versión v0.16.0, publicada como un lanzamiento inmutable con atestiguación.
• Verifica los archivos descargados usando el comando de la CLI de GitHub gh release verify-asset v0.16.0 FILE para garantizar la integridad.
• Habilita la inmutabilidad de los lanzamientos en tus propios repositorios de GitHub para prevenir la modificación no autorizada de activos de lanzamiento existentes.
• Fija los hashes SHA-256 en las tuberías CI/CD y los scripts de instalación en lugar de depender de etiquetas latest dinámicas o descargas sin comprobar.
• Audita los niveles de acceso de los colaboradores y aplica la autenticación multifactor para reducir el riesgo de compromiso de cuentas.