OVHcloud CLI downloads were swapped for a stealer for 94 minutes

OVHcloud CLI downloads were swapped for a stealer for 94 minutes

20 October 2026: An attacker used a compromised contributor account to replace the downloadable binaries of five existing releases of OVHcloud's official command-line tool, v0.11.0 to v0.15.0, with a build that steals credentials. The swap ran from 12:47 UTC on 19 October until OVHcloud deleted the files at 14:21 UTC; v0.16.0, published at 17:16 UTC as an immutable release with an attestation, is clean.

Which downloads were replaced

On each affected release the attacker swapped the macOS (arm64 and x86_64), Linux (x86_64 and arm64) and Windows x86_64 archives, and the checksums.txt file, so a checksum check against the release's own list would have passed. The Linux i386, Windows i386, Windows arm64 and WASM builds were left alone, as was v0.10.0. The source repository and the CI pipeline were not touched: the bad binary was built from a commit merged on 13 October and uploaded by hand through the contributor's account.

The problem surfaced fast because one downstream user had pinned the SHA-256 of a release in their own CI. That job failed at 13:50 UTC, the user opened an issue, and OVHcloud pulled the assets half an hour later.

How you could have picked it up

Researchers at OpenSourceMalware, who published the timeline, list the install routes that fetched the swapped files during the window:

• the install.sh script in the repository
• brew install --cask ovh/tap/ovhcloud-cli or brew upgrade
• direct downloads from the GitHub Releases page
• CI jobs and Dockerfiles that fetch release tarballs by URL

go install, building from source and the ovhcom/ovhcloud-cli Docker image were not affected, nor were installs made before 12:47 UTC and not updated during the window.

Checking a binary and what to rotate

On a suspect machine, go version -m on the binary tells the builds apart: the malicious one reports vcs.modified=true and a version ending in +dirty, and it does not answer ovhcloud version with a release tag. The clean hashes are in the v0.16.0 release, and gh attestation verify works from v0.16.0 on. On macOS, a file at ~/init.json is a marker the malware leaves.

If an affected build ran, the researchers' advice is to "treat every secret readable from that machine as exposed" and rotate from a different machine: OVH API and consumer keys and ~/.ovh.conf, other cloud credentials, SSH keys, package registry tokens, Kubernetes configs and .env files. OVHcloud's own advisory lists what the malware goes after: data from several AI coding assistants and editors, AWS, Google Cloud and Azure credentials, Docker, Kubernetes and npm configuration, SSH keys, Terraform credentials, .netrc and the global Git config. It copies them to a folder named envchecker followed by digits in the temp directory, archives it, and sends it out through Solana RPC calls and an upload to the address 45.32.148.174. OVHcloud puts downloads of the bad binaries at about 250.

What OVHcloud has said

According to Help Net Security, OVHcloud chief executive Octave Klaba confirmed the incident on X, said release immutability had not been switched on for the repository and now is, and promised a post-mortem in the coming days. The researchers trace the contributor account's compromise back to March, when its personal repositories were force-pushed with a loader, and link it to the GlassWorm campaign. We list OVHcloud among the 200 firms in our web hosting category.

Sources

• OpenSourceMalware: GlassWorm hacks OVH Cloud's CLI tool, 20 October 2026
• GitHub: ovh/ovhcloud-cli releases, 19 October 2026
• Help Net Security: OVHcloud CLI on GitHub served malware, 21 October 2026
• OVHcloud: ovhcloud-cli security incident, October 19th, 2026 (GHSA-862f-55f5-vmvw), 20 October 2026