El ataque a la herramienta de línea de comandos de OVHcloud, que el 19/10/2026 sirvió durante algo más de hora y media binarios diseñados para robar secretos, no explotó ninguna vulnerabilidad del código: bastó una cuenta de GitHub comprometida y un ajuste de seguridad desactivado. El atacante sustituyó los archivos de descarga de cinco versiones ya publicadas de OVHcloud CLI, de la v0.11.0 a la v0.15.0, y además manipuló el fichero de sumas de comprobación para que todo pareciera legítimo.
Las claves del ataque a OVHcloud CLI en 30 segundos
- El atacante usó la cuenta de un colaborador con permisos de escritura y resubió los binarios de cinco versiones existentes.
- También alteró checksums.txt, así que comprobar el hash contra ese archivo no servía de nada.
- Los binarios estuvieron disponibles entre las 12:47 y las 14:21 UTC; lo detectó el pipeline de un cliente con el hash fijado.
- Homebrew, Docker y las compilaciones desde el código fuente no se vieron afectados, según The Hacker News.
- Quien ejecutara un binario afectado debe dar por expuestos todos los secretos de esa máquina.
Los hechos básicos los contamos en Revista Cloud, en el artículo sobre las cinco versiones manipuladas del CLI de OVHcloud. Aquí nos centramos en lo que interesa a un equipo de seguridad: cómo saber si un binario es uno de los comprometidos, qué falló en la cadena de publicación y qué controles habrían evitado o reducido el impacto.
Cómo comprobar si un binario es uno de los manipulados
OVHcloud no ha publicado todavía indicadores de compromiso completos, pero la reconstrucción de The Hacker News aporta varios para la versión v0.15.0. El más directo es el hash del paquete para Linux ARM64:
Paquete manipulado (v0.15.0, Linux arm64):
SHA-256 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb
Paquete original (v0.15.0, Linux arm64):
SHA-256 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0Como la herramienta está escrita en Go, el propio binario guarda información de cómo se compiló. Se puede consultar con go version -m indicando la ruta del ejecutable:
go version -m /ruta/al/binario/de/ovhcloud-cliEn el binario manipulado aparece una pseudoversión del tipo v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, que remite al commit 5ead8ef, cuando la etiqueta v0.15.0 apunta al 760fd72. También muestra una línea -ldflags="-s -w" que no tienen las versiones auténticas. Ojo con la marca +dirty: por sí sola no prueba nada, porque la versión limpia v0.16.0 también la muestra.
Para los paquetes de la v0.11.0 a la v0.14.0 no hay hashes públicos del contenido malicioso. Si alguien no puede determinar qué versión descargó ni cuándo, lo prudente es tratar la máquina como comprometida. La incidencia #300 del repositorio ovh/ovhcloud-cli recoge la información que se ha ido compartiendo.
Qué falló en la cadena de publicación
El fallo no está en el código, que sigue intacto, sino en cómo se publicaban las versiones. GitHub permite borrar y volver a subir los archivos adjuntos a una versión ya publicada con el mismo nombre, de modo que la URL de descarga no cambia. El ajuste de inmutabilidad de versiones lo impide, pero solo protege las versiones creadas después de activarlo, y en el repositorio de OVHcloud no estaba activado. Octave Klaba, fundador de la compañía, lo ha reconocido públicamente.
El atacante tampoco necesitó tocar la integración continua: compiló los binarios por su cuenta, a partir de un commit posterior, y los subió a mano. El dato más relevante para cualquier equipo es otro. Al reemplazar también checksums.txt, el atacante neutralizó la comprobación que muchos usuarios hacen al descargar. Un hash que se descarga del mismo sitio que el binario no protege frente a quien controla ese sitio. Lo que sí funcionó fue un hash fijado de antemano en el pipeline de un cliente: la descarga no coincidía, el trabajo falló y el cliente abrió una incidencia pública.
Sobre el origen, los investigadores de OpenSourceMalware sostienen que la cuenta usada llevaba meses comprometida y la relacionan con la campaña GlassWorm. Se basan en un cargador que obtiene su siguiente fase del campo memo de una cartera de Solana, una técnica asociada a esa campaña. Ellos mismos lo presentan como una inferencia, y nada del binario de octubre se ha vinculado todavía a GlassWorm.
Controles que conviene revisar
Si el equipo publica software en GitHub o depende de binarios descargados de versiones de GitHub, estos son los puntos que el caso deja sobre la mesa:
- Activar la inmutabilidad de versiones en los repositorios propios, sabiendo que no cubre las versiones anteriores a su activación.
- Publicar atestaciones de los artefactos y verificarlas al descargar, por ejemplo con
gh release verify-asset, en lugar de confiar en un checksums.txt del mismo origen. - Fijar hashes o versiones exactas en scripts, imágenes base y pipelines, para que un cambio silencioso rompa el proceso en vez de colarse.
- Reducir los permisos de escritura a las cuentas que realmente publican y exigir autenticación fuerte, porque una cuenta de colaborador basta para reemplazar binarios.
- Rotar secretos desde otra máquina si se ejecutó un binario sospechoso: claves de la API de OVHcloud en ~/.ovh.conf y variables de entorno, claves SSH, tokens de nube y credenciales de Git.
OVHcloud ya ha activado la inmutabilidad, ha publicado la v0.16.0 como versión inmutable y ha prometido un informe posterior con más detalles sobre el binario, incluidos los ficheros que intenta leer y adónde envía la información.
Preguntas frecuentes
¿Cómo sé si tengo un binario manipulado de OVHcloud CLI?
Compara su hash con el publicado para la v0.15.0 de Linux ARM64 y revisa la salida de go version -m: los binarios manipulados apuntan al commit 5ead8ef y muestran un ldflags que no tienen los originales.
¿Por qué no sirvió comprobar el hash con checksums.txt?
Porque el atacante también reemplazó checksums.txt para que coincidiera con los binarios maliciosos. Solo detecta el cambio un hash fijado de antemano o una atestación verificable.
¿Qué es la inmutabilidad de versiones de GitHub?
Es un ajuste que impide modificar los archivos de una versión una vez publicada. Solo protege las versiones creadas después de activarlo.
¿Está confirmado que detrás está GlassWorm?
No. OpenSourceMalware relaciona la cuenta usada con esa campaña, pero lo presenta como una inferencia y no hay vínculo confirmado con el binario.
Fuentes:
- Revista Cloud: OVHcloud CLI, cinco versiones manipuladas para robar secretos
- Octave Klaba (@olesovhcom) en X
- The Hacker News: Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware
- BleepingComputer: OVHcloud CLI releases backdoored on GitHub to steal developer secrets
- GitHub: repositorio ovh/ovhcloud-cli
