OVHcloud CLI GitHub Release Hijack: Rotate Secrets and Upgrade to v0.16.0

What happened​

OVHcloud is the French cloud and hosting provider. Its open-source CLI lets admins and developers manage OVHcloud services from a terminal and automate those tasks. The compromised versions are v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0. CEO Octave Klaba confirmed the list and said v0.10.0 and the new v0.16.0 are clean. OVHcloud CEO Octave Klaba said the affected releases were v0.11.0, v0.12.0, v0.13.0, v0.14.0, and v0.15.0.

The source code was not changed. OpenSourceMalware, a community threat-intelligence platform, investigated the incident. It found that the uploads were made through the GitHub account HassenBF, a legitimate OVH contributor, using the ordinary GitHub Releases API. No tag was pushed and no GitHub Actions workflow ran. The researchers say the malicious binary was a go build from a workstation with uncommitted changes, dropped straight onto existing releases.

That's why OVHcloud's automated checks didn't help. Klaba said the unit tests, functional tests and CVE detection in the CI/CD pipelines were all unaffected. The attacker never went through the pipeline. They uploaded new files to releases that had already passed it.

Summary: the source was clean and the download buttons served malware. If your security model only covers your build pipeline, this is the gap it misses.

The timeline, in UTC​

Early reports give two sets of times, but they describe the same window. GBHackers, following Klaba's post, wrote that the company identified the compromised release at 14:47 and detected and blocked it by 16:21, creating a 94-minute exposure window. Those are Paris times. In UTC:

OpenSourceMalware's report says between 12:47 and 13:12 UTC, an attacker replaced the release binaries of five already-published versions. The Hacker News reports the files were live for up to 94 minutes, from 12:47 to 14:21 UTC, and that the last step came at 17:16 UTC, OVHcloud published clean CLI v0.16.0 through its ovh-cds account with a signed tag, an immutable release, and a release attestation.

OVHcloud didn't catch this itself. A customer's pinned hash did. A customer's CI job detected a mismatch against its pinned SHA-256 hash for the Linux arm64 archive. The customer after inspecting the suspicious binary without executing it, ... filed GitHub issue #300 at 13:50 UTC. The repository had no private channel for reporting vulnerabilities, so the warning went into a public issue.

Which files and platforms were affected​

According to The Hacker News, the attacker replaced six files on v0.15.0:

• macOS x86_64 and ARM64 archives
• Linux x86_64 and ARM64 archives
• Windows x86_64 archive
• checksums.txt, edited so the published hashes matched the malicious binaries

The same six files are now gone from v0.11.0 through v0.14.0. The Linux i386, Windows i386, Windows ARM64 and WebAssembly builds were not touched on any release. If you're on Windows on Arm, you weren't served a swapped archive.

The edited checksums.txt matters. If your check compares a download against a hash file from the same release page, it passed, because the attacker controlled both. Only a hash pinned before the incident would have failed, and that's how the customer caught it.

Were you exposed? It depends on how you installed​

Reports agree on several routes and disagree on one.

Likely exposed if you were on an affected platform during the window and you:

1. Ran the official install script (curl … install.sh | sh). The Hacker News says it downloads the latest release archive and has never checked a hash.
2. Downloaded an archive directly from one of the five release pages.
3. Had a CI job or build step that fetched a release archive without a pinned hash.
4. Ran the CLI's own upgrade command from v0.12.0, v0.13.0 or v0.14.0 on macOS or Linux, where the tool was installed by script or by hand. The Hacker News says the command replaces the binary without a hash check.

Not exposed, according to The Hacker News, if you:

• Used go install or built from source. The v0.15.0 tag still points at its original September commit, 760fd72.
• Pulled the Docker image. Its latest tag was last pushed on September 21 and hadn't been rebuilt as of October 20.
• Installed before 12:47 UTC on October 19 and didn't update during the window. The version number alone doesn't mean you were hit.

Homebrew is disputed. OpenSourceMalware's report says anyone who ran install.sh, brew install --cask ovh/tap/ovhcloud-cli, or downloaded a tarball from GitHub in that window on macOS, Linux x86_64/arm64 or Windows x86_64 got the malware. The Hacker News reviewed the tap's commit history and disagrees. It found the cask pinned the original SHA-256 of each archive and didn't change between September 16 and the v0.16.0 cask on October 19, so Homebrew would have refused the swapped file and failed the install. The Hacker News's evidence is more specific. Still, if you ran brew upgrade during the window and anything odd happened, treat it as a possible exposure.

What the malware did, and what nobody knows yet​

Klaba said the payload was built to "retrieve secrets from the disk." He called the binary poor quality but warned it "can go all the way." No public analysis exists. OpenSourceMalware didn't analyze the payload, and The Hacker News reports that no copy of a swapped archive has been analyzed publicly. OVHcloud hasn't said which files the binary reads, where it sends them, or how many people downloaded it. The company has promised a detailed postmortem.

So be careful with any claim about exactly what was stolen. Theft hasn't been confirmed. The risk is clear, though, and OVHcloud's advice reflects that.

How to check a binary without running it​

The customer who caught the swap used go version -m, which reads Go build metadata without executing the file. The Hacker News lists three signs of the bad build:

• The module line shows a pseudo-version, v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, instead of a tagged version.
• The recorded commit is 5ead8ef, not 760fd72.
• An -ldflags="-s -w" line is present. OVHcloud's genuine release builds show no -ldflags line.

The Hacker News warns against using +dirty alone as the test. The clean v0.16.0 also reports +dirty and vcs.modified=true. The only published hash of a swapped file is for the v0.15.0 Linux arm64 archive: 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb. The original is 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0. Don't run a suspect binary to check its version.

What to do now​

1. Rotate secrets first, from a different machine. If you ran a swapped build, or can't tell, Klaba's advice is to change every secret stored on the disk. The Hacker News notes that the CLI keeps OVHcloud API credentials in ~/.ovh.conf and reads them from environment variables. The advice covers more than that: SSH keys, cloud tokens, Git credentials, anything that machine could read. OpenSourceMalware recommends doing the rotation from a different, clean machine.
2. Remove the binary and install v0.16.0. Installing the new version replaces the program. It doesn't revoke keys that may already have been copied, which is why rotation comes first.
3. Verify the download. v0.16.0 has a release attestation. The Hacker News points to gh release verify-asset v0.16.0 FILE, as GitHub documents, for checking a downloaded archive.
4. Audit CI runners and build hosts. Look for jobs that fetched the CLI from GitHub release URLs on October 19 between 12:47 and 14:21 UTC. Runners often hold the most useful secrets.
5. Pin hashes. One customer's pinned SHA-256 caught this attack. Pinning costs little and saves a lot.

How the hole was left open, and what's still open​

Klaba said GitHub's release immutability setting was turned off, so a sufficiently privileged account could change existing releases without passing through CI/CD. OVHcloud has now turned it on and considers the incident closed. IT-Connect's French edition quoted his message: "The option has been enabled. End of the incident."

There's a catch. IT-Connect notes that according to GitHub's documentation, immutability only applies to releases published after it is enabled, unless they are republished. In its words, it therefore protects v0.16.0 and later, but not releases v0.10.0 to v0.15.0, which remain technically modifiable by an account with write access. Immutability also stops changes to a published release. It doesn't stop a compromised privileged account from publishing a malicious new release. It's one layer of defense, not a complete fix.

My view: OVHcloud responded quickly and openly. The CEO posted updates the same evening, a clean immutable release was out within hours, and the company apologized. The weak points were basic ones. An install script that pipes to sh without checking hashes, an upgrade command that does the same, and a repository with release immutability off are common, and this attack used all three.

The GlassWorm question​

OpenSourceMalware believes the attack is linked to GlassWorm, a campaign active since late 2025 that has hit the VS Code, OpenVSX, GitHub and npm ecosystems. The researchers say the contributor account was already compromised and had been for seven months. Its public repositories show a scripted history rewrite on 5 March 2026 and a hidden preinstall.js loader that decodes to a second stage using a Solana memo dead drop. They add that the wallet is a known GlassWorm indicator, and the amend-and-force-push technique matches the ForceMemo campaign.

That's an inference, and the researchers say so. The only link is the shared account. As IT-Connect put it, nothing proves that the person who booby-trapped those repositories in March is the same one who replaced the OVHcloud CLI binaries in October, and how the credentials were stolen remains unknown. The open question is how an account with write access to a major cloud provider's tooling stayed compromised for about seven months without anyone noticing. The postmortem should address that.

Bottom line: if your machine ran an affected binary between 12:47 and 14:21 UTC on October 19, assume its secrets are exposed. Rotate them from a clean device, install v0.16.0, and pin your hashes.