OVHcloud retira cinco versiones de su CLI tras un ataque a la cadena de suministro

Una herramienta oficial para administrar servicios en la nube se convirtió durante 94 minutos en un vehículo para robar secretos. OVHcloud retiró cinco versiones de su interfaz de línea de comandos ovhcloud-cli después de descubrir que sus binarios habían sido reemplazados por archivos maliciosos en un ataque a la cadena de suministro.

El incidente fue revelado el 20 de octubre de 2026 y afecta a las versiones v0.11.0, v0.12.0, v0.13.0, v0.14.0 y v0.15.0. Quienes descargaron una de ellas deben asumir que los secretos accesibles desde el equipo pudieron quedar expuestos, incluso si la herramienta parecía funcionar normalmente.

Qué ocurrió con ovhcloud-cli

Según la información publicada por OVHcloud y recogida por medios especializados, un atacante obtuvo acceso temporal al proceso de publicación de lanzamientos en GitHub. El acceso permitió reemplazar los artefactos compilados de cinco versiones por ejecutables alterados, sin modificar el código fuente del repositorio.

Los archivos contaminados estuvieron disponibles entre las 12:47 y las 14:21 UTC del 19 de octubre. OVHcloud revocó credenciales, retiró los lanzamientos afectados y publicó la versión limpia e inmutable v0.16.0. La compañía también indicó que su código fuente y sus pipelines de construcción no fueron alterados, aunque el riesgo se trasladó a los equipos que ejecutaron los binarios manipulados.

Ese matiz importa: el ataque no necesitaba entrar a cada cuenta de OVHcloud. Bastaba con alterar una herramienta confiable para que administradores y desarrolladores instalaran el código malicioso por su cuenta.

Qué información pudo quedar expuesta

OVHcloud describió el archivo añadido como un programa diseñado para recopilar secretos almacenados en el disco. Hasta la publicación de esta alerta no existe un ejemplar preservado y analizado públicamente, por lo que no se conoce la lista exacta de archivos leídos, el destino de los datos ni cuántas descargas maliciosas ocurrieron.

La recomendación oficial es tratar como expuesto cualquier secreto que pudiera leer el usuario que ejecutó la CLI. En una estación de administración o desarrollo, eso puede incluir:

Tokens y credenciales de OVHcloud usados por la propia CLI.
Claves SSH que podían permitir acceso a servidores y repositorios.
Tokens de GitHub y NPM con potencial para comprometer código o paquetes.
Credenciales de AWS y otros secretos de entornos cloud.
Información almacenada por navegadores, billeteras de criptomonedas y herramientas de desarrollo.

Investigadores de OpenSourceMalware vincularon la cuenta de GitHub comprometida con infraestructura observada previamente en la campaña GlassWorm. Sin embargo, ningún componente del binario malicioso de octubre ha sido ligado técnicamente a esa familia y OVHcloud no ha atribuido el incidente. La relación debe considerarse una inferencia, no una atribución definitiva.

Por qué este ataque supera el riesgo de una CLI aislada

Una CLI cloud suele ejecutarse en computadores con privilegios operativos altos. Allí conviven archivos de configuración, tokens de automatización, llaves de despliegue y acceso a repositorios. Por eso, una sola ejecución puede abrir varias puertas al mismo tiempo.

El atacante podría utilizar un token robado para modificar infraestructura, una llave SSH para entrar a servidores o una credencial de GitHub para alterar otro proyecto. Esa capacidad de encadenar accesos convierte un incidente breve en un problema que puede persistir después de retirar el archivo original.

También demuestra una debilidad recurrente de la cadena de suministro: las organizaciones suelen confiar en el nombre del proyecto y en la página oficial de descarga, pero no siempre verifican firmas, hashes o procedencia del proceso de compilación.

Qué deben hacer quienes instalaron una versión afectada

Eliminar el ejecutable no es suficiente. Si una de las versiones comprometidas fue descargada o ejecutada, la respuesta debe tratar el equipo como potencialmente expuesto.

Desinstalar la versión afectada y actualizar a una versión limpia publicada por OVHcloud.
Revocar y rotar de inmediato tokens de OVHcloud, GitHub, NPM, AWS y cualquier secreto disponible en el equipo.
Reemplazar claves SSH que estuvieran almacenadas localmente, no solo cambiar su frase de paso.
Revisar registros de auditoría en servicios cloud, repositorios y gestores de paquetes desde el momento de la descarga.
Buscar persistencia o actividad anómala en el equipo y, ante evidencia de ejecución, considerar una reconstrucción desde una imagen confiable.

Los equipos de seguridad también deberían buscar instalaciones de ovhcloud-cli en inventarios de endpoints y pipelines. En entornos grandes, la herramienta pudo haberse distribuido automáticamente mediante scripts o imágenes de desarrollo.

Lecciones para proteger la cadena de suministro

El caso OVHcloud refuerza una regla básica: una descarga oficial no garantiza por sí sola que el archivo sea seguro. Las empresas necesitan controles que validen artefactos antes de ejecutarlos y que limiten el daño si un proveedor es comprometido.

Verificar hashes y firmas criptográficas cuando el proveedor los publique.
Separar credenciales por entorno y aplicar permisos mínimos.
Evitar secretos permanentes en estaciones de trabajo y preferir tokens de corta duración.
Monitorizar el uso de credenciales fuera de horarios, regiones o flujos habituales.
Mantener un inventario de herramientas de desarrollo y sus versiones.

El tiempo de exposición fue limitado, pero la ventana no elimina el riesgo. En la automatización moderna, 94 minutos bastan para que un binario sea descargado por pipelines, contenedores o equipos de desarrollo en distintos países.

Referencias oficiales y técnicas

Conclusión: quienes ejecutaron cualquiera de las cinco versiones deben actuar ahora. La prioridad no es solo actualizar la CLI, sino invalidar los secretos que el malware pudo leer y comprobar que no hayan sido utilizados.