Get a free audit

Field Notes / Supply Chain

Five OVHcloud CLI releases turned into stealers for 94 minutes. A pinned hash caught it.

On 19 October 2026 an attacker used a hijacked developer account to swap the binaries of OVHcloud CLI v0.11.0 to v0.15.0 for a build that copied cloud keys, SSH keys and AI assistant data off every machine that ran it. About 250 downloads landed in the window. Homebrew users were safe and one customer’s CI noticed in an hour. Here is why the release page’s own checksums proved nothing, and the five checks that close the same gap in your toolchain.

Author
Red Team Partners
Read
8 MIN READ
Filed
23 Oct 2026
A system administrator in a data centre, the person who installs the cloud CLI and keeps its keys on the same laptop.

01 What happened on 19 October

customer’s build broke. Their CI pinned the SHA-256 of ovhcloud-cli_Linux_arm64.tar.gz from v0.15.0, a release published on 16 September. On the afternoon of 19 October the hash changed. They pulled the new binary apart, found a local go build of a later commit with uncommitted changes, and opened issue #300 on the repository asking whether it was intentional Issue #300 . It was not.

19 Oct, Paris timeWhat
14:47v0.15.0 macOS binary replaced
14:57All v0.15.0 binaries replaced, plus its checksums.txt
15:30Binaries of v0.11.0 to v0.14.0 replaced
15:50Customer reports the swap in a public GitHub issue
16:21OVHcloud deletes every malicious binary
18:52Public announcement on X
19:16Clean v0.16.0 released with a signed tag, as an immutable release

The timeline comes from OVHcloud’s own advisory, published the next day OVHcloud 2026 . From report to clean-up took 31 minutes. That is a fast response. It still left an hour and a half in which anyone running the install script got the stealer.

The root cause goes back a year. OVHcloud traced it to an extension, color-picker-universal 2.8.91, which the developer installed on a personal MacBook on 20 October 2025. The extension called a Solana wallet that researchers had already tied to the GlassWorm campaign. Several of the developer’s personal repositories were tampered with in March 2026. The release swap itself was done with the stolen keys, from elsewhere. OVHcloud says the developer’s work laptop was not compromised as far as it knows OVHcloud 2026 .

02 Who was safe, and why

The install path decided everything. Same software, same day, five different outcomes.

Install pathExposed?Why
brew install --cask ovh/tap/ovhcloud-cliNoThe cask records each archive’s SHA-256 at release time. A swapped file fails the check
install.sh piped to shYesThe script downloads the latest archive and checks no hash
Manual download from GitHub releasesYesThe attacker also rewrote checksums.txt, so the page vouched for its own malware
go install or source buildNoThe git tags were never moved. v0.15.0 still pointed at the real commit
Docker image ovhcom/ovhcloud-cliNoReported unaffected by the researchers at OpenSourceMalware

GitHub has a setting built for this. An immutable release locks its tag and assets once published, and GitHub signs an attestation of what was in it GitHub Docs . You can then check a release with gh release verify. The OVHcloud CLI repository did not have it switched on, which OVHcloud names as the main issue. It is now on across the organisation. Releases published before that change stay editable unless they are republished.

03 What the stealer took

OVHcloud’s first public description said the binary was built to grab secrets from disk. The advisory has the full list. The malware went well past OVH credentials:

  • Cloud accounts. AWS (including S3), Google Cloud and Azure credentials and configuration, plus DigitalOcean’s doctl config.
  • Infrastructure access. Kubernetes and Docker configuration, Terraform credentials, SSH keys, .netrc, npm configuration and the global git config.
  • AI assistants. Local databases of VS Code, Cursor, Continue, Sourcegraph Cody and OpenCode, sessions of the Hermes agent, and the Claude agent’s configuration and data directory.

That last group is the trend to watch. AI coding assistants keep provider keys, chat history and pasted code on the developer’s disk. We saw stolen AI keys turn into real bills after the OpenCode Console breach three days earlier. The GhostAction workflows in GitHub are hunting for the same keys in commits (our note on GhostAction).

The stealer copied everything into a temp folder named envchecker- plus nine or ten digits, archived it, and sent it to a server it looked up through Solana RPC calls. It never deletes that folder. If the folder exists on a machine, the binary ran there OVHcloud 2026 .

04 A sovereign cloud still ships through GitHub

Many European companies pick OVHcloud because it is French and holds their data under European law. That choice covers the data centre. The laptop where your engineer keeps the API keys sits outside it, and so does the tool that put them there.

OVHcloud is candid about the split. Its production CI/CD runs on private, internal git servers, audited and untouched by this incident. GitHub is where it publishes tools for customers, and there the controls were looser: a managed organisation with mandatory 2FA, but developers attach their personal GitHub accounts to it, "as do most of tech companies" OVHcloud 2026 . Two-factor authentication did not help, because the attacker used keys stolen from the developer’s own Mac.

Swap OVHcloud for any provider and the picture holds. Your cloud contract covers the region. Your actual exposure runs through every CLI, Terraform provider and SDK your team pulls from a public release page, each one published by a person with a personal account and a personal laptop. This CLI ran on machines that also held AWS, Azure and Google keys, and it took all of them.

05 Five checks for this week

Do the first one today if anyone in your company uses the OVHcloud CLI. The rest apply to any tool you install from a release page.

This week
  • Find every machine and CI runner that installed or updated the OVHcloud CLI on 19 October. Without running it, compare the binary’s MD5 against the five hashes in advisory GHSA-862f-55f5-vmvw and look for an envchecker folder in the temp directory. Where either matches, rotate OVH API keys first, then every cloud, SSH, registry and AI provider credential on that machine, and confirm the old ones fail
  • Upgrade to v0.16.0 and check it with gh release verify v0.16.0 -R ovh/ovhcloud-cli before you trust it
  • Pin a SHA-256 for every binary your pipelines download, recorded at the time you first approved it and stored in your own repository. Never compare against a checksums file served from the same release page
  • Replace curl-pipe-to-shell installs on developer machines with a package manager that pins hashes, or with go install or a source build at a fixed tag
  • If you publish tools on GitHub yourself, turn on immutable releases for the organisation, republish your current releases, and require signed tags. Then check who can upload release assets and whether those accounts are personal

One customer with one pinned hash caught this in about an hour. Most teams have no such tripwire. Their build would have installed the new binary without complaint. We can show you how many of yours would. In 14 days you get every tool that reaches your engineers’ machines and pipelines, which ones verify what they install, which secrets sit beside them, and the change that closes each gap. Start with your Threat Map, from $5,000.

References

Sources

  1. OVHcloud. ovhcloud-cli security incident, 19 October 2026. GitHub security advisory GHSA-862f-55f5-vmvw, published 20 October 2026. github.com
  2. alink-tothepast. Release assets of v0.13.0–v0.15.0 replaced on 2026-10-19 with a dirty build of a later commit. ovh/ovhcloud-cli issue #300, 19 October 2026. github.com
  3. The Hacker News. Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware. October 2026. thehackernews.com
  4. IT-Connect. OVHcloud CLI binaries on GitHub were tampered with by an infostealer. October 2026. it-connect.tech
  5. GitHub Docs. Immutable releases. docs.github.com