Compromised OVHcloud CLI release archives v0.11.0 to v0.15.0 (2026-10-19, 94 minutes): reinstall v0.16.0 and rotate cloud, SSH, npm and AI-tool credentials

View raw markdownEdit on GitHub ↗

TL;DR

If you downloaded, installed or upgraded ovhcloud-cli v0.11.0 through v0.15.0 between 12:47 and 14:21 UTC on 2026-10-19 and ran it, delete the binary and reinstall v0.16.0, the immutable release the vendor published that evening. The vendor says secrets on that machine "should be considered compromised": rotate cloud, container, Kubernetes, Terraform, SSH, Git, npm and AI-tool credentials from a different machine.

Packages and versions

Ecosystem Name Bad versions Clean version or action Registry state (date checked) Record
GitHub release assets (ovh/ovhcloud-cli) ovhcloud archives for Darwin_arm64, Darwin_x86_64, Linux_arm64, Linux_x86_64 and ovhcloud.exe Windows_x86_64 v0.11.0, v0.12.0, v0.13.0, v0.14.0, v0.15.0 as served 2026-10-19 12:47 to 14:21 UTC (the v0.15.0 Darwin archive from 12:47, all v0.15.0 archives from 12:57, all five releases from 13:30) delete; install v0.16.0 (2026-10-19 17:16 UTC, signed tag, marked immutable) replaced files deleted 14:21 UTC; v0.16.0 is the only release marked immutable (2026-10-20) GHSA-862f-55f5-vmvw (vendor, 2026-10-20, High, no CVE)
GitHub release assets the same releases, Linux i386, Windows i386, Windows arm64 and WebAssembly builds none replaced, per the vendor and the reporter no action unchanged same
Homebrew cask, go install, source builds, Docker image ovhcloud-cli none: the cask pinned the original hashes and refused the download, the v0.15.0 tag still points to its original commit, the image's latest tag was not rebuilt no action unchanged same

Per the vendor advisory: a compromised OVHcloud developer's GitHub account, registered to the organisation, was used to replace the archives and checksum file of already-published releases; the source code, tags, build chain and internal CI/CD were not affected; the root cause named is that "the GitHub repository was not appropriately configured to ensure release immutability," since corrected. The reporter (issue #300, opened 2026-10-19) was a customer whose CI job pins the archive's SHA-256 and failed; they noted the replacement assets were uploaded by a different account than the originals and carried build metadata of a later, uncommitted commit. Public announcement 16:52 UTC; private vulnerability reporting enabled afterwards. The Hacker News attributes a link between the uploading account and the GlassWorm campaign to researchers and calls it an inference, with nothing from the October binary tied to GlassWorm.

Am I affected?

  • Only if you fetched an affected archive inside the window and ran it. Downloads before 12:47 UTC on 2026-10-19, and installs of v0.10.0 or earlier or v0.16.0 or later, are not affected per the vendor.
  • The exposure paths The Hacker News lists: the official install script, which downloads the latest archive without a hash check; manual downloads from the five release pages; CI steps fetching release archives without a pinned hash; the CLI's upgrade command on macOS or Linux for installs from v0.12.0 to v0.14.0 that were not made through Homebrew or go install.
  • The vendor's checks: look in the temp directory for a directory named envchecker- followed by random digits, and compare the installed binary's checksum with the values in the advisory's appendix. Do not run the binary to check it.
  • Verify a fresh download with gh release verify-asset v0.16.0 <file> (per The Hacker News) before trusting it.

If you are affected

  1. Delete the binary and reinstall v0.16.0 or later. Updating does not revoke anything already copied, so rotation comes first and happens from a different machine.
  2. Rotate or deactivate, per the vendor's list: AWS (~/.aws/credentials, ~/.aws/config, ~/.aws/cli/cache); Google Cloud (~/.config/gcloud/credentials.db, access_tokens.db, configurations/config_default); Azure (~/.azure/azureProfile.json, clouds.config, config, msal_token_cache.json); Docker and Kubernetes (~/.docker/config.json, ~/.dockercfg, ~/.kube/config); DigitalOcean, Terraform, ~/.netrc and ~/.npmrc; SSH keys and ~/.gitconfig; AI tools (~/.claude, ~/.hermes/sessions, ~/.hermes/.hermes_history, the OpenCode databases under ~/.local/share/opencode/ and ~/.config/opencode/); the VS Code and Cursor globalStorage/state.vscdb stores and the Continue and Sourcegraph Cody databases beside them; and OVHcloud API credentials in ~/.ovh.conf or environment variables. The vendor says any other secret readable from disk should be treated the same way.
  3. Follow rotating cloud credentials, if your GitHub PAT leaked and if your npm token leaked for the order of operations, and if you ran malicious postinstall for the host.
  4. Pin hashes in every CI and build step that fetches release archives, and prefer the Homebrew cask or go install paths that already do.

Prevention

  • CI/CD hardening: pin the hash of every downloaded release asset; a pinned job is what caught this one.
  • Supply-chain attack surface: a release page is mutable unless the repository enables release immutability, and a tag pointing at the right commit says nothing about the archive next to it.
  • Credential hygiene: the vendor's rotation list is the inventory of what a CLI on a developer laptop can read.

StepSecurity names the GitHub account used (HassenBF), confirms the 12:47 to 14:21 UTC window and that v0.16.0 was published clean at 17:16 UTC, and notes that release immutability was not enabled on the repository, which is why assets could be replaced in place. Defender signals it lists: a /tmp/envchecker-* file, a ~/init.json file, a binary whose ovhcloud version prints undefined, and a build stamped with a commit (5ead8ef…) that does not exist in the repository; file hashes for the replaced archives are on the post. The loader fetched its second stage through a blockchain dead-drop in the GlassWorm style, which is the basis for the campaign link. Credits: alink-tothepast, Ivan Kwiatkowski, OpenSourceMalware.

Sources