OVHcloud CLI Releases Hijacked to Steal Developer Secrets

October 19, 2026: OVHcloud confirmed that an attacker used a hijacked contributor's GitHub account to replace the download files on five releases of its command-line tool, ovhcloud-cli (v0.11.0 to v0.15.0), with a build designed to steal secrets from any machine that runs it. The swapped files were live for up to 94 minutes. Canonical: ovhcloud-cli-github-release2026. Primary sources: the GitHub issue that caught it and OVHcloud's guidance as reported by The Hacker News.

ovhcloud-cli is how developers and CI pipelines manage OVHcloud infrastructure from a terminal, so it typically runs on laptops and build servers that hold cloud API credentials, SSH keys and tokens for other services. That is what makes a short window dangerous: one run of a malicious binary on a build agent can hand over everything that agent can reach.

What happened

On Monday, October 19, an attacker logged into GitHub with the account of a contributor who had write access to OVHcloud's repositories. Instead of touching the source code or the build pipeline, they edited five releases that had already been published between April 14 and September 16, replacing six files on each:

• the macOS x86_64 and arm64 archives,
• the Linux x86_64 and arm64 archives,
• the Windows x86_64 archive,
• and checksums.txt, so the published hashes matched the malicious files.

The swapped files went live at 12:47 UTC. At 13:50 a customer's CI job, which pinned the original SHA-256 of the Linux arm64 archive, started failing, and the customer opened a public GitHub issue. OVHcloud deleted the files at 14:21 UTC and later published a clean v0.16.0 from its own release account with a signed tag, immutability enabled, and a release attestation.

Technical analysis

Why this worked

GitHub lets anyone with write access edit the files attached to an existing release unless the repository turns on immutable releases. OVHcloud had not. OVHcloud's CEO Octave Klaba said the problem stemmed from immutability not being enabled, that it now is, and that the pipelines were not affected. Because the attacker rewrote checksums.txt too, anyone who verified downloads against the published checksums would still have seen a match. Only users who had pinned hashes from before the attack, like the customer whose CI broke, could tell.

What was and was not affected

• Affected: direct downloads, the repository's install script, and the tool's built-in upgrade command for v0.11.0 to v0.15.0 on the five platforms above, during the 94-minute window.
• Not affected: Homebrew (its cask pins the original hashes), go install and source builds (the v0.15.0 tag still points to the original commit 760fd72), the Docker image, and the Linux i386, Windows i386, Windows arm64 and WebAssembly builds. Version v0.10.0 is listed as clean.

The payload

OVHcloud says the build was designed to steal secrets stored on disk. It has not said which files it reads, where it sends them, or how many copies were downloaded, and no sample had been analysed publicly by October 20. The Hacker News reported indicators for a swapped build: a module version of v0.15.1-0.20261013083505-5ead8ef9b43d+dirty and commit 5ead8ef instead of 760fd72. OVHcloud advises against running a suspect binary just to check.

Impact

The exposure depends entirely on what was on the machine. A developer laptop or CI runner can hold OVHcloud API keys, credentials for other clouds, SSH keys, package-registry tokens and .env files. Any of those on a machine that ran a swapped build should be considered stolen. OVHcloud has not published a download count, so the number of affected users is unknown.

Who is at risk

• CI/CD pipelines that fetch the latest ovhcloud-cli release by URL or through the install script on every run, without pinning a hash. A pipeline that ran during the window probably executed the malicious build on an agent that holds deployment credentials.
• Developers who upgraded on October 19 using the tool's built-in upgrade command or a fresh download from the GitHub releases page between 12:47 and 14:21 UTC.
• Teams that copied the binary into internal images that day. A golden image or container built from a swapped archive keeps the malware after the release itself was cleaned up, so rebuild anything produced in that window.
• Not at risk: people who installed through Homebrew, go install or a source build, people who used the Docker image, and anyone who did not download the tool during the window.

Verified vs unverified

• Verified (OVHcloud): the compromised account, the affected versions and files, the timeline, and that source and pipelines were untouched.
• Unverified: researchers at OpenSourceMalware tie the hijacked account to the GlassWorm campaign, citing a loader force-pushed to its personal repositories in March. They call this "our inference", and nothing in the October binary has been linked to GlassWorm.
• Unknown: how the contributor's credentials were obtained, what the malware exfiltrates, and how many people downloaded it. OVHcloud has promised a postmortem.

What to do

1. Work out whether you were exposed. You are at risk if you downloaded or upgraded ovhcloud-cli v0.11.0 to v0.15.0 on October 19 between 12:47 and 14:21 UTC by direct download, install script, or the built-in upgrade. Check CI logs for that window.
2. If yes, or if you cannot tell, rotate every secret on that machine: OVHcloud keys, other cloud credentials, SSH keys, Git and registry tokens, and anything in environment files. Do it from a different, clean machine.
3. Remove the binary and install v0.16.0, then verify it with gh release verify-asset v0.16.0 FILE.
4. Pin hashes for third-party binaries in CI. It is the control that caught this attack.
5. If you publish releases, turn on immutable releases and require hardware-backed 2FA for everyone with write access.

Related incidents

This is the third software supply-chain compromise in two days. Rank Math PRO shipped a backdoored WordPress plugin (our write-up) and AOMEI's update servers pushed malware to backup software users (our write-up). For earlier attacks that went after developer secrets, see LiteLLM / TeamPCP and Shai-Hulud in npm.

Sources

The Hacker News • BleepingComputer • GitHub issue #300 • ovhcloud-cli v0.16.0 • Next (French)