Cloud Security Wire
AWS Azure GCP RSS
Multi-Cloud Breach Analysis high

OVHcloud CLI Releases v0.11.0 to v0.15.0 Compromised: Check Your Version and Rotate Your Secrets

OVHcloud says five releases of its CLI on GitHub carried a binary built to pull secrets from disk. Here is what is reported so far, how to check whether you are exposed, and a rotation checklist.

By Cloud Security Wire · ·
#OVHcloud#supply chain#GitHub releases#credential theft#secret rotation#CLI security#Glassworm
High Severity

This issue has been assessed as high severity. Review affected configurations immediately.

What has been reported

OVHcloud’s command line tool, ovhcloud, had its GitHub releases tampered with. Everything below comes from a single news report, The Stack’s coverage, which we opened on 22 October 2026 and which was updated on 21 October with OVHcloud’s post-mortem. We also tried OVHcloud’s US support article but it returned HTTP 403, so we have not independently confirmed the details against a vendor advisory. Treat the specifics as single-source until you have checked OVHcloud’s own notice.

As reported:

  • Affected versions: v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0. v0.10.0 and the upcoming v0.16.0 are described as clean.
  • Payload: CEO Octave Klaba said the attacker added a binary “whose job is to retrieve secrets from the disk”, and called its quality “poor but it can go all the way”. OVHcloud said research on the binary was ongoing.
  • Detection: a customer reported it on 19 October 2026, and the malicious release was reportedly spotted and blocked within 94 minutes.
  • Scope: Klaba said initial checks found “no other repo is affected”.
  • Guidance: “If you are affected, please change all the secrets on your disk.”

How it happened, per OVHcloud

According to the post-mortem as relayed by The Stack, the attacker used one developer’s GitHub account to replace the release binary. OVHcloud traced the original compromise to a malicious editor extension, color-picker-universal 2.8.91, installed on that developer’s personal MacBook on 20 October 2025. It says a Solana wallet in the extension is associated with the Glassworm threat actor, and that a persistent NodeJS service talked to 162.33.177[.]177. The Stack also reports that other personal repositories of the same account were compromised in March 2026.

The main root cause OVHcloud gives is that the repository “was not appropriately configured to ensure release immutability”. It says that is now fixed across all its repositories.

Our assessment: the lesson is less about OVHcloud than about any project that ships binaries through a release page. A release asset that can be silently replaced by one stolen account is a single point of failure for every user who downloads it. No install-count figure was found as of 22 October 2026 in the sources we opened.

Are you exposed?

The official getting started guide lists three install routes: a piped install.sh script, Homebrew (brew install --cask ovh/tap/ovhcloud-cli) and a manual download from GitHub releases. The report names GitHub releases as the affected channel. It does not say whether Homebrew or the install script served the bad builds, so we would check all three.

Test in a non-production account first, and run these on a clean workstation or a copy of the machine where you can:

# Which version is installed? (command from OVHcloud's docs)
ovhcloud version

# Where is the binary, and when was it last modified?
ls -l "$(command -v ovhcloud)"

# Hash it, so you can compare against a known-good build later
sha256sum "$(command -v ovhcloud)"

If the version is anywhere from 0.11.0 to 0.15.0, assume the secrets readable by your user were exposed. Note that this includes more than OVHcloud credentials. The reported payload targets secrets on disk generally, so our assessment is that anything in your home directory is in scope.

Rotation checklist

  1. OVHcloud API credentials. The CLI docs say credentials live in ~/.ovh.conf (application key, application secret, consumer key) or in the OVH_APPLICATION_KEY, OVH_APPLICATION_SECRET and OVH_CONSUMER_KEY environment variables. Revoke and recreate them in your OVHcloud account, then run ovhcloud login again from a clean install.
  2. Cloud keys on the same machine. Check ~/.aws, ~/.azure, ~/.config/gcloud, ~/.kube and ~/.ssh. Rotate anything long-lived. For AWS access keys, create the replacement first, switch your tooling, then disable the old one:
aws iam list-access-keys --user-name <user>
aws iam create-access-key --user-name <user>
aws iam update-access-key --user-name <user> \
  --access-key-id <OLD_KEY_ID> --status Inactive
  1. Tokens in dotfiles and shells. Rotate GitHub and registry tokens, CI secrets, .env files and anything in shell history.
  2. Reinstall cleanly. Remove the binary, then install v0.10.0 or v0.16.0 once it is available, and verify against checksums published by the vendor.
  3. Review logs. Look at provider audit logs for API calls from unfamiliar IPs since you installed the affected version. As an example on AWS, CloudTrail’s lookup-events can filter by AccessKeyId:
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=<KEY_ID> \
  --max-results 50

Hardening your own release process

If you publish binaries, take the same lesson. Our recommendations, informed by the reporting rather than taken from OVHcloud:

  • Turn on release immutability where your platform supports it, so published assets cannot be swapped.
  • Publish only from a locked-down build pipeline with required approval, as The Stack argues.
  • Never fix a bad release by replacing the asset. Cut a new version instead.
  • Require phishing-resistant MFA and keep personal and work machines separate for anyone with release rights.
  • On the consumer side, pin versions, verify checksums or signatures and avoid piping scripts into a shell on production hosts.

Still unverified

  • No OVHcloud advisory was reachable to us (HTTP 403), so every incident detail is from one outlet.
  • We found no public indicator list beyond the single IP above, and no analysis of the binary, as of 22 October 2026 in the pages listed here.
  • Whether Homebrew or the install script distributed the affected builds is not stated in the sources we opened.

Check OVHcloud’s official channels for updates before acting on anything here.

← All Analysis Subscribe via RSS