VULNpocalypse
HighSupply chainPatch available

OVHcloud CLI v0.11.0 to v0.15.0: GitHub release binaries and checksums.txt swapped for an infostealer for 94 minutes

OVHcloud CLI binaries for v0.11.0 to v0.15.0 fetched on 19 Oct 2026, 12:47 to 14:21 UTC, were an infostealer. Check MD5s, rotate secrets, install v0.16.0.

Published
Updated
Fixed in
v0.16.0 (immutable release). Builds up to v0.10.0, go install and the ovhcom/ovhcloud-cli Docker image were not affected
Exploitation
Yes. OVHcloud counted about 250 downloads of the malicious binaries

What happened

On 19 October 2026 a compromised OVHcloud developer GitHub account replaced release binaries on five already-published versions of ovh/ovhcloud-cli, v0.11.0 to v0.15.0. The source code, tags and OVHcloud’s build pipeline were not changed. Releases were not set to immutable, so an account with write access could overwrite assets (OVHcloud advisory GHSA-862f-55f5-vmvw).

Timeline in UTC, from OVHcloud (which gives Paris time, UTC+2):

  • 12:47: the v0.15.0 Darwin binary was replaced. By 12:57 all v0.15.0 binaries were.
  • 13:30: binaries for v0.15.0 down to v0.11.0 had been replaced.
  • 13:50: a customer opened a public issue after their CI pipeline, which pins the SHA-256 of the Linux arm64 archive, started failing (issue 300).
  • 14:21: OVHcloud deleted all malicious binaries.
  • 17:16: v0.16.0 was published with a signed tag as an immutable release.

The attacker also rewrote checksums.txt, so checking a download against the release page would have matched (IT-Connect). Replaced assets were the Darwin arm64, Darwin x86_64, Linux arm64, Linux x86_64 and Windows x86_64 archives; Linux i386, Windows i386, Windows arm64 and wasm were untouched (issue 300). OVHcloud counted about 250 downloads.

Root cause. OVHcloud traced the account takeover to the developer installing the extension color-picker-universal 2.8.91 on a personal MacBook on 20 October 2025. Its Solana wallet is attributed to the GlassWorm group. The uploads were made with the stolen keys, not from that laptop (OVHcloud advisory). OpenSourceMalware shows the account, HassenBF, had personal repositories rewritten with a GlassWorm loader in March 2026 (OpenSourceMalware).

What the stealer does

All details from the OVHcloud advisory.

The fake binary is the real CLI rebuilt with an extra envchecker module. Each run creates a folder named envchecker- plus 9 or 10 digits in the temp directory, copies files into it, archives it and uploads it to https://45.32.148[.]174/upload. It also makes Solana RPC calls tied to wallet BHaDaVbdCYFNaKZGn7yLXFneWoJHZgLiBYkHxVrjyALF. The folder is never deleted. It takes:

  • AI coding tools: VS Code and Cursor state.vscdb, the Continue extension index, Sourcegraph Cody chat history, OpenCode’s database, Hermes agent sessions, and the whole ~/.claude directory.
  • Cloud: ~/.aws/credentials, ~/.aws/config, ~/.aws/cli/cache, gcloud credentials.db and access_tokens.db, Azure profile and msal_token_cache.json, ~/.config/doctl/config.yaml, ~/.terraform.d/credentials.tfrc.json.
  • Developer: ~/.ssh, ~/.kube/config, ~/.docker/config.json, ~/.dockercfg, ~/.netrc, ~/.gitconfig and npm configuration.

Am I affected?

Only the GitHub release assets, the official install.sh script that downloads them and, in principle, the CLI’s built-in update command are in scope, and only during the window. go install, building from source and the ovhcom/ovhcloud-cli Docker image were not affected (IT-Connect; OpenSourceMalware).

Look for the stealer’s working folder first. It is left behind on every run:

bash
ls -d "${TMPDIR:-/tmp}"/envchecker-* /tmp/envchecker-* 2>/dev/null

On Windows, check %TEMP% for envchecker-*. Then hash the binary without running it and compare with OVHcloud’s list of malicious MD5s:

bash
md5sum "$(command -v ovhcloud)"     # Linux
md5 "$(command -v ovhcloud)"        # macOS
# Darwin arm64   6f2f086239f3d88eb2750e871901927d
# Darwin x86_64  347e65eb7f2d78d1c6872690272a6cc3
# Linux arm64    01f57206d37c28cf711677f612052913
# Linux x86_64   301bff0b51980b9e76c93633e7cfd3bd
# Windows x86_64 (ovhcloud.exe) 6a3cf153338c416169cda2fe704c8848

Go build metadata also gives it away. The malicious build reports v0.15.1-0.20261013083505-5ead8ef9b43d+dirty and vcs.modified=true, while official builds report the release tag (OVHcloud advisory):

bash
go version -m "$(command -v ovhcloud)" | grep -E 'mod|vcs.modified'

If you kept the archive, the malicious v0.15.0 ovhcloud-cli_Linux_arm64.tar.gz has SHA-256 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb; the original was 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0 (issue 300). In CI, check logs for downloads from github.com/ovh/ovhcloud-cli/releases in the window. Search egress logs for 45.32.148.174 and for Solana RPC hosts (solana.drpc.org, solana-rpc.publicnode.com, solana.api.pocket.network, api.mainnet-beta.solana.com, solana.api.onfinality.io) from machines with no reason to call them.

What to do now

  1. Rotate from a different, clean machine every credential the stealer reads: OVHcloud API keys and ~/.ovh.conf, AWS, Google Cloud, Azure, DigitalOcean and Terraform credentials, SSH keys, kubeconfig, Docker and npm registry tokens, anything in ~/.netrc and .env files (OVHcloud advisory; OpenSourceMalware).
  2. Treat AI assistant data as exposed. ~/.claude and the VS Code, Cursor, Continue, Cody and OpenCode databases can hold API keys, tokens and pasted secrets. Rotate the API keys those tools use.
  3. Delete the binary and the envchecker-* folder after you have kept a copy for investigation, then install v0.16.0 or later (OVHcloud advisory).
  4. Pin what you download. Releases v0.10.0 to v0.15.0 were published before immutability was enabled, so their assets can still be edited by anyone with write access (IT-Connect). Pin a SHA-256 recorded from v0.16.0 or later, or build with go install at a tag. OpenSourceMalware suggests checking v0.16.0 provenance with gh attestation verify.

Why this matters

A checksum file hosted next to the binary only proves the two were uploaded together. Here both were replaced. What caught it was a CI job that had recorded the hash before the attack. Immutable releases, signed provenance or a hash you pinned yourself are the only checks that hold when the publisher’s account is the thing that was stolen.

Sources