The OVHcloud CLI Supply Chain Attack

What happened

A GitHub account with write access uploaded new files over the existing release assets of ovh/ovhcloud-cli. Issue #300 names the uploader as HassenBF. OVHcloud describes it as a compromised developer account. No tag moved and no CI job ran. The v0.15.0 tag still points to commit 760fd72d.

The OVHcloud advisory and issue #300 give this timeline. The advisory uses UTC+2. The times below are UTC on 19 October 2026.

A customer caught the swap. Their CI pinned the SHA-256 of the v0.15.0 Linux arm64 archive. The new file did not match, so their builds failed. The reporter, alink-tothepast, opened issue #300 and showed that the new binary came from a different commit.

The swapped binary is not a release build. Issue #300 reports the module version v0.15.1-0.20261013083505-5ead8ef9b43d+dirty. It points to commit 5ead8ef9b43d354dfb5caadff803b11afc8c5c58 on the main branch, dated 13 October 2026. The build also reports vcs.modified=true and lacks the version flag that the project's GoReleaser setup adds.

OVHcloud says a malicious extension compromised a developer's personal machine months earlier. The attacker then used stolen GitHub credentials to replace the release assets. StepSecurity names the extension as the VS Code extension color-picker-universal 2.8.91, installed on 20 October 2025. It left a NodeJS backdoor that talked to 162.33.177[.]177. OVHcloud says the attack did not reach its internal CI/CD system. The repository did not use GitHub's immutable releases setting. That gap let an account with write access replace files at existing download links.

The swapped binary carries a module named envchecker that steals credentials and files. The OVHcloud advisory and StepSecurity list these targets:

• Cloud command-line tools for AWS, Google Cloud, Azure and DigitalOcean
• Docker and Kubernetes configuration
• Terraform and npm credentials
• SSH keys, .netrc and .gitconfig
• Data stores of AI coding tools. StepSecurity names Claude, Cursor, VS Code, Continue, Cody, OpenCode and Hermes.

The stealer copies the data into a temp folder named envchecker- followed by digits. StepSecurity reports that it never deletes this folder. It packs the data as a tar.gz file and encodes it in base64. It wraps the result in JSON shaped like a Solana RPC call and posts it to 45.32.148[.]174. It steals again on every run. In the StepSecurity lab, it collected 18 secret paths into one 1,949-byte archive about four seconds after install.

StepSecurity also found a GlassWorm loader in personal repositories of the same GitHub account. In March 2026, force-pushes added a hidden preinstall.js to four of those repositories. StepSecurity recovered one copy from an orphaned commit in HassenBF/next-dashboard. The loader hides its code in invisible variation-selector characters. It reads the address of its next stage from the memo of a Solana wallet. For the earlier GlassWorm wave, see the GlassWorm attack on Open VSX.

Affected versions

Five releases carried swapped binaries: v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0. Only downloads made on 19 October 2026 between 12:47 and 14:21 UTC are affected.

• Affected files (advisory): ovhcloud for Darwin_arm64, Darwin_x86_64, Linux_arm64 and Linux_x86_64, and ovhcloud.exe for Windows x86_64.
• OVHcloud says a download made before the window is not affected.
• Clean: v0.10.0 and earlier.
• Clean: v0.16.0 and later. OVHcloud released v0.16.0 with a signed tag as an immutable release.
• Issue #300 reports that the v0.15.0 i386, Windows arm64 and wasm assets did not change.
• Issue #300 reports that the uploader also replaced checksums.txt in v0.13.0, v0.14.0 and v0.15.0. The published checksums then matched the bad files.

StepSecurity checked each install path. Its results:

StepSecurity disputes other reports that list Homebrew as an infection path.

Indicators of compromise

The OVHcloud advisory lists the binary hashes and network indicators. Issue #300 and StepSecurity add the archive hash, the build marks and the loader.

• Malicious v0.15.0 Linux_arm64 archive SHA-256 (issue #300): 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb
• Original v0.15.0 Linux_arm64 archive SHA-256 (issue #300): 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0
• Build version string: v0.15.1-0.20261013083505-5ead8ef9b43d+dirty
• Build commit: 5ead8ef9b43d354dfb5caadff803b11afc8c5c58
• Upload server: 45.32.148[.]174:443, path /upload. The advisory notes that this address can change.
• Solana wallet (advisory): BHaDaVbdCYFNaKZGn7yLXFneWoJHZgLiBYkHxVrjyALF
• Solana RPC hosts (advisory): solana.drpc[.]org, solana-rpc.publicnode[.]com, solana.api.pocket[.]network, api.mainnet-beta.solana[.]com, solana.api.onfinality[.]io/public. These are public Solana services.
• Staging folder: envchecker- followed by 9 or 10 digits in the temp folder, for example /tmp/envchecker-*
• Re-run marker on macOS (StepSecurity): ~/init.json
• 2025 backdoor server (advisory and StepSecurity): 162.33.177[.]177
• GlassWorm loader preinstall.js SHA-256 (StepSecurity): 43df42fd79f6f81e530892b54634598770d6e496796a863c596e616bcb3fec70
• Decrypted loader stage 2 SHA-256 (StepSecurity): 0f79989912572a24ba13baabb32b3fd084496271c51448d47b66fe1aedbf293c
• Loader dead-drop wallet (StepSecurity and advisory): BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC

How to check

Check the binary's build data and hash without running it. The OVHcloud advisory says to check the hash without running the binary. These commands only read files.

If Go is installed, read the build data from the binary.

go version -m $(which ovhcloud) | head -5

If the output shows 5ead8ef9b43d or v0.15.1-0.20261013083505, the binary is the swapped build.

Compute the MD5 of the binary and compare it with the table above. On Linux, use md5sum. On macOS, use md5.

md5sum $(which ovhcloud)

md5 $(which ovhcloud)

On Windows, run this in the folder that holds ovhcloud.exe.

certutil -hashfile ovhcloud.exe MD5

Look for the staging folders and the macOS marker file.

ls -d /tmp/envchecker-* "${TMPDIR:-/tmp}"/envchecker-* ~/init.json 2>/dev/null

In CI, search your build logs for downloads of v0.11.0 to v0.15.0. Look at jobs that ran on 19 October 2026 between 12:47 and 14:21 UTC.

grep -rE "ovhcloud-cli/releases/download/v0\.1[1-5]\.0/" <log-folder>

If any check matches, treat the machine or runner as compromised. StepSecurity says to treat every credential on a matching CI runner as exposed.

What to do now

1. Do not run the ovhcloud binary to test it. Check its hash and build data first.
2. If the binary matches, or you downloaded v0.11.0 to v0.15.0 in the window, treat every secret on that machine as stolen.
3. From a different machine, rotate OVHcloud API keys and cloud keys for AWS, Google Cloud, Azure and DigitalOcean.
4. Also rotate kubeconfigs, Docker and registry credentials, npm tokens, Terraform credentials, SSH keys, .netrc entries, Git credentials and AI tool tokens.
5. Revoke and reissue personal access tokens used on the machine since 19 October 2026.
6. Delete the binary and every envchecker- folder in the temp folder.
7. Install v0.16.0 or later. Check the file with gh release verify-asset v0.16.0 <file>.
8. If you cannot confirm that the machine is clean, rebuild it.
9. Pin release hashes in CI. A pinned hash is what caught this attack.

What Vigilance would show (rebuilt from public reports)

Vigilance compares the version you trust with the new one and names the file that gained a new power. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 79

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

CHANGED    ovhcloud-cli.exe
           It now reads saved passwords and access keys. It did not before.

Sources

1. github.com/ovh/ovhcloud-cli/security/advisories/GHSA-862f-55f5-vmvw
2. github.com/ovh/ovhcloud-cli/issues/300
3. stepsecurity.io/blog/ovhcloud-cli-github-release-swap-glassworm