OVHcloud ha confirmado que un atacante sustituyó los binarios publicados de cinco versiones de su herramienta de línea de comandos, OVHcloud CLI, por otros diseñados para robar los secretos guardados en el disco del equipo que los ejecuta. El incidente ocurrió el lunes 19/10/2026 y afecta a las versiones v0.11.0, v0.12.0, v0.13.0, v0.14.0 y v0.15.0 descargadas desde GitHub. Quien instalara o actualizara la herramienta ese día debe borrarla, instalar la v0.16.0 y cambiar todas las credenciales de su equipo.
Las claves del ataque al CLI de OVHcloud en 20 segundos
- Versiones comprometidas: de la v0.11.0 a la v0.15.0. La v0.10.0 y la nueva v0.16.0 están limpias, según OVHcloud.
- Los archivos maliciosos estuvieron publicados entre las 14:47 y las 16:21, hora peninsular.
- El atacante usó la cuenta de GitHub de un desarrollador.
- Si te afecta, cambia todos los secretos del equipo.
El aviso lo dio el propio fundador de OVHcloud, Octave Klaba, en la red social X. Un detalle para no confundirse: «14:47» no es un número de versión, sino la hora a la que apareció la versión manipulada. OVHcloud la detectó y la bloqueó a las 16:21, después de que un cliente avisara del problema, y una primera revisión no encontró ningún otro repositorio afectado.
Qué pasó en el repositorio de GitHub
Según Klaba, el atacante utilizó la cuenta de GitHub de uno de los desarrolladores del proyecto y añadió un binario «cuyo trabajo es recuperar secretos del disco». El propio Klaba matiza que «la calidad del binario es pobre, pero puede llegar hasta el final». La compañía sigue analizando el código malicioso y ha prometido publicar más detalles.
La reconstrucción de The Hacker News y de los investigadores de OpenSourceMalware añade contexto. El atacante no tocó el código fuente, las etiquetas ni la cadena de integración continua: borró y volvió a subir con el mismo nombre los archivos de descarga de versiones ya publicadas, compilados por su cuenta. Pudo hacerlo porque el repositorio no tenía activada la inmutabilidad de versiones de GitHub, una opción que impide modificar una versión después de publicarla. Klaba ha reconocido que ese ajuste estaba desactivado y OVHcloud ya lo ha activado.
En la versión v0.15.0 se reemplazaron los paquetes para macOS (Intel y Apple Silicon), Linux (x86_64 y ARM64) y Windows x86_64, además del archivo checksums.txt, que se alteró para que las sumas de comprobación publicadas coincidieran con los binarios maliciosos. Fue precisamente un proceso de integración continua de un cliente, que tenía fijado el hash original, el que detectó el cambio y abrió una incidencia pública. Cómo se robaron las credenciales del desarrollador no se ha explicado. OpenSourceMalware relaciona esa cuenta con la campaña GlassWorm, aunque lo presenta como una inferencia propia que no está confirmada.
Quién está afectado y qué hacer
El riesgo se concentra en quien descargó manualmente o por script uno de esos binarios desde GitHub durante la ventana del ataque, o actualizó la herramienta con su propio comando de actualización en ese intervalo. Según The Hacker News, no estaban expuestos quienes la instalaron con Homebrew, que tenía fijados los hashes originales, ni quienes la compilaron desde el código fuente o usaron la imagen de Docker. OVHcloud no ha dicho cuántas copias se descargaron.
La herramienta guarda las credenciales de la API de OVHcloud en el archivo ~/.ovh.conf y también las lee de variables de entorno, así que son lo primero que hay que cambiar. Pero la recomendación de OVHcloud es más amplia: cambiar todos los secretos del disco, lo que incluye claves SSH, tokens de otros proveedores de nube, credenciales de Git y contraseñas guardadas en archivos de configuración. Los pasos recomendados son estos:
- Borrar el binario afectado e instalar la v0.16.0, publicada como versión inmutable.
- Cambiar las credenciales desde otro equipo, no desde la máquina que ejecutó el binario.
- Revocar las claves de la API de OVHcloud y regenerarlas, además del resto de secretos del equipo.
- Verificar las descargas antes de usarlas y fijar los hashes en los scripts y en la integración continua.
Para comprobar que un archivo descargado corresponde a la versión oficial, GitHub permite verificarlo con su herramienta de línea de comandos:
gh release verify-asset v0.16.0 NOMBRE_DEL_ARCHIVO --repo ovh/ovhcloud-cliEl caso llega pocos días después de que algunas copias de Rank Math SEO PRO 3.0.123 se distribuyeran con malware, otro ataque que llegó por el canal oficial de descarga. En el de OVHcloud no hubo un fallo exótico: bastó una cuenta comprometida con permisos de escritura y una protección de GitHub sin activar. Esta vez el golpe cae sobre una herramienta pensada precisamente para gestionar servidores y credenciales de nube.
Preguntas frecuentes
¿Qué versiones de OVHcloud CLI están comprometidas?
Las v0.11.0, v0.12.0, v0.13.0, v0.14.0 y v0.15.0 descargadas desde GitHub el 19/10/2026. Según OVHcloud, la v0.10.0 y la v0.16.0 están limpias.
¿La versión 14.47 de OVHcloud CLI existe?
No. 14:47 es la hora a la que apareció la versión manipulada, no un número de versión. OVHcloud la bloqueó a las 16:21.
¿Me afecta si instalé OVHcloud CLI con Homebrew o Docker?
Según The Hacker News, no: Homebrew tenía fijados los hashes originales y la imagen de Docker no se modificó. Las compilaciones desde el código fuente tampoco se vieron afectadas.
¿Qué hago si ejecuté una versión afectada?
Borra el binario, instala la v0.16.0 y cambia desde otro equipo todos los secretos que hubiera en esa máquina, empezando por las credenciales de la API de OVHcloud.
Fuentes:
