OVHcloud CLI: cinco versiones secuestradas para robar secretos
Con la cuenta de GitHub de un desarrollador, un atacante sustituyó los binarios de OVHcloud CLI de la 0.11.0 a la 0.15.0: a quién afecta y qué hacer ya.

El 19 de octubre de 2026 un atacante usó la cuenta de GitHub de un desarrollador de OVHcloud para sustituir los binarios de cinco versiones ya publicadas de OVHcloud CLI, la herramienta de código abierto de línea de comandos con la que administradores y desarrolladores gestionan y automatizan los servicios cloud y de hosting del proveedor francés. En lugar de los archivos originales apareció un binario cuya función, según el fundador y CEO Octave Klaba, es recuperar los secretos presentes en el disco. Lo han publicado BleepingComputer, SecurityWeek y The Hacker News; los detalles técnicos que siguen proceden de las declaraciones de Klaba en X y del análisis de la plataforma comunitaria OpenSourceMalware, recogidos por los dos primeros medios.
Qué ha pasado
Las versiones comprometidas son v0.11.0, v0.12.0, v0.13.0, v0.14.0 y v0.15.0. La 0.10.0 y la nueva 0.16.0 están limpias. Según Klaba, la versión comprometida apareció a las 14:47 (hora de París) y se bloqueó a las 16:21, tras el aviso de un cliente: una ventana de unos 94 minutos. OpenSourceMalware, citada por SecurityWeek, indica que un usuario señaló públicamente la manipulación en GitHub después de que fallara una comprobación automática del hash.
La causa que da OVHcloud es de configuración: la opción release immutability de GitHub estaba desactivada. Una cuenta con los permisos adecuados podía, por tanto, modificar directamente las versiones existentes sin pasar por la pipeline de CI/CD. Klaba precisa que las pipelines, con pruebas unitarias, pruebas funcionales y detección de CVE, no se vieron afectadas. La opción ya está activada y, según BleepingComputer, OVHcloud da el incidente por resuelto.
Klaba describe el binario como «de mala calidad, pero puede llegar hasta el final», y pide a los afectados que limpien el sistema y cambien todos los secretos presentes en el disco.
Detalles técnicos
Según OpenSourceMalware, el atacante no usó la CI/CD: subió binarios compilados en local sobre los archivos originales de versiones ya publicadas. Solo se sustituyeron las compilaciones de las plataformas más comunes, un indicio que para los investigadores apunta a la recogida de credenciales en los equipos de desarrollo y de operaciones:
- afectados: macOS (Intel y ARM), Linux x86_64 y ARM64, Windows x86-64, si se instalaron o actualizaron durante la ventana mediante el script de instalación oficial, Homebrew o la descarga directa desde GitHub;
- no afectados: quien compiló desde el código fuente, quien usó el comando de instalación de Go y quien usa la imagen Docker oficial.
El payload no se ha analizado: OpenSourceMalware no pudo obtener una muestra antes de que OVHcloud borrara los archivos. Por eso no hay indicadores públicos (hashes, dominios, direcciones) del binario distribuido con la CLI.
La cuenta pertenece a un colaborador legítimo de OVHcloud y, según los investigadores, estaba comprometida al menos desde marzo de 2026: el 5 de marzo se reescribió con un script el historial de cuatro de sus repositorios personales, y en tres apareció un loader oculto (preinstall.js). La siguiente fase del loader consulta la blockchain Solana (un dead drop en el campo memo de las transacciones) para saber de dónde descargar el payload, usando un wallet que es un indicador conocido de GlassWorm, la campaña activa desde finales de 2025 contra los ecosistemas VS Code, OpenVSX, GitHub y npm.
El vínculo con GlassWorm hay que leerlo con cautela: los propios investigadores escriben que la idea de que el mismo actor comprometiera la cuenta en marzo y atacara la CLI en octubre es una deducción suya, y OVHcloud no ha mencionado GlassWorm en sus declaraciones.
En nuestra lectura, las técnicas MITRE ATT&CK pertinentes son T1195.002 (Compromise Software Supply Chain), T1078 (Valid Accounts), T1552.001 (Credentials In Files) y, para el loader de los repositorios personales, T1102.001 (Dead Drop Resolver).
Impacto para las empresas europeas e italianas
OVHcloud es uno de los principales proveedores cloud europeos y muchas empresas alojan allí servicios e infraestructuras. La CLI se ejecuta en las máquinas con más privilegios: equipos de administradores y desarrolladores, servidores de gestión y runners de CI/CD. Son las mismas máquinas que guardan claves API, claves SSH, tokens y archivos de configuración de otros entornos, así que la exposición puede ir más allá de la cuenta de OVHcloud.
Para las entidades sujetas a NIS2, la seguridad de la cadena de suministro y del desarrollo es una de las medidas exigidas: un binario malicioso ejecutado en un equipo con acceso a la infraestructura debe valorarse también como posible incidente que notificar, según los accesos realmente obtenidos.
Qué hacer ya
- Localiza las instalaciones: busca OVHcloud CLI en equipos, servidores y runners, y comprueba si se instaló o actualizó el 19 de octubre entre las 14:47 y las 16:21 hora de París (12:47–14:21 UTC) con el script oficial, Homebrew o la descarga desde GitHub. También cuentan las imágenes de contenedor construidas en esa ventana descargando el binario.
- Sustituye el binario por la 0.16.0, o compila desde el código fuente. Si tienes una 0.11.0–0.15.0 y no sabes cuándo se descargó, trátala como sospechosa.
- Considera comprometidos todos los secretos de la máquina que ejecutó un binario afectado, como pide Klaba: credenciales API de OVHcloud y de otros clouds, claves SSH, tokens de Git y de los registros, archivos
.envy configuraciones. Rótalos y revoca los antiguos. - Revisa el uso de las credenciales desde el 19 de octubre en los registros de los proveedores: accesos desde direcciones inusuales, claves nuevas, cambios en la infraestructura.
- Limpia o reinstala las máquinas afectadas: sin un análisis del payload no se sabe si deja persistencia.
- Refuerza la cadena de suministro: fija las versiones de las herramientas y verifica los hashes antes de instalar, como hizo el usuario que descubrió la manipulación. Si publicas software en GitHub, activa la release immutability, exige MFA a los colaboradores y vigila los cambios en los archivos de las versiones ya publicadas.
Cómo ayuda ARXDOME
Con su agente, ARX Sentry recoge el inventario de software y procesos de ordenadores y servidores Windows, Linux y macOS, y te permite encontrar rápidamente las máquinas donde está instalada la CLI. Si una máquina es sospechosa, ARX Shield te permite aislarla de la red mientras se limpia y se rotan sus secretos.
Última actualización:


