OVHcloud CLI releases 0.11.0 to 0.15.0 were swapped for a secret-stealing build on GitHub: what to check and rotate

OVHcloud says attackers replaced the downloadable binaries of five releases of its open-source command-line tool, ovhcloud-cli, with a build that steals secrets from disk. The tampered files were on GitHub for about an hour and a half on 19 October 2026 before OVHcloud deleted them. Anyone who installed or updated the tool in that window on macOS, Linux or Windows should treat the machine's credentials as exposed. The source code and CI pipelines were not touched, which makes this a useful case study in how a single hijacked developer account can poison a software supply chain.

Key points

• OVHcloud CEO Octave Klaba said versions 0.11.0 to 0.15.0 of the OVHcloud CLI were modified on GitHub; 0.10.0 and the latest release, 0.16.0, are clean.
• Per Klaba, the bad files appeared at 14:47 Paris time on 19 October (12:47 UTC) and were blocked at 16:21 Paris time (14:21 UTC) after a customer reported them.
• The attacker used a developer's hijacked GitHub account to swap release files; OVHcloud says its CI/CD pipelines and tests were not affected, and that GitHub's release immutability setting had been off.
• If you ran an affected binary, OVHcloud says to change all secrets stored on the disk; source builds and Docker images were unaffected.
• OpenSourceMalware, a community threat-intelligence group, links the compromised account to the GlassWorm campaign but says it has not analysed the payload.

What happened

According to BleepingComputer's report and the CEO's statements it quotes, the attacker took over a developer's GitHub account and used it to modify existing releases in OVHcloud's ovhcloud-cli repository, versions 0.11.0 through 0.15.0. Klaba said the compromised release appeared at 14:47 on 19 October and was "detected and blocked at 16:21 after a customer reported it". Those are Paris times; OpenSourceMalware converts them to 12:47 and 14:21 UTC, which we use below.

OpenSourceMalware, which built a timeline from GitHub's server-side records, says the files were replaced between about 12:47 and 13:12 UTC, so they were swapped for roughly 25 minutes and available to download for 94. It says the first sign of trouble was a downstream user whose CI pinned the SHA-256 checksum of the Linux arm64 archive; the job failed, and the user filed a public issue on the repository at 13:50 UTC. OVHcloud deleted the replaced files at 14:21 UTC, and a clean, immutable v0.16.0 was published later that afternoon.

Klaba described the malicious binary as poor quality ("it can go all the way", he said) and said its purpose was to retrieve secrets from the disk. In a later update he said the release immutability setting on GitHub had been disabled, "allowing a sufficiently privileged account to modify existing releases without passing CI/CD checks", and that the pipelines with unit tests, functional tests and CVE detection were not impacted. OVHcloud has since enabled release immutability and considers the incident resolved, while asking affected users to rotate secrets.

Background

The OVHcloud CLI is OVHcloud's official terminal tool for managing cloud and hosting services, used by administrators and developers for scripting. Installers such as the project's install.sh script and its Homebrew cask download binaries from GitHub Releases. That is why replacing a release file, rather than changing source code, reached users: anyone fetching the same release URL got the swapped file, and nothing in the URL changed.

This is a recurring pattern. We have covered several recent cases where trusted distribution channels were abused, including the Rank Math PRO 3.0.123 malware, the ConnectWise Cloud Backup supply-chain attack and the OpenCode breach.

GitHub's immutable releases feature, when turned on, stops existing release assets from being modified or deleted after publication. OVHcloud's CEO confirms it was off for this repository until now.

How it works

OpenSourceMalware's analysis is the most detailed account so far, and we flag where it is its own inference. Its key findings:

• It was not the build system. The release workflow only runs when a version tag is pushed, and the group says GitHub's server-side records show no workflow run between 16 October and the 19 October tag for v0.16.0. The uploads were made through GitHub's Releases API by a human contributor's account, not by the account that originally published those releases. The group notes that repository administrators can delete workflow runs, a caveat on that reading.
• The binary was built on a workstation. Go binaries embed build information. The reporter who caught the swap read it with go version -m and found a "+dirty" version stamp marking uncommitted changes and a commit from 13 October, whereas the project's official release build strips that information and sets a clean version. OpenSourceMalware reads that as a build made on a laptop with local modifications.
• The attacker was selective. Only the mainstream targets were replaced: macOS Intel and ARM, Linux x86_64 and arm64, Windows x86_64, and the checksum file, so that published hashes matched the new binaries. The 32-bit builds, Windows arm64 and the WebAssembly build were left alone. The group concludes this looks like credential harvesting from developer and operations workstations.
• The account had been compromised for months. It says the account's 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 blockchain memo as a "dead drop", and that the wallet appears in public GlassWorm indicator lists. GlassWorm is a campaign known since late 2025 for hitting VS Code, OpenVSX, GitHub and npm ecosystems. Whether the same actor did both the March activity and the October swap is, in the researchers' own words, their inference.

What it means

For developers who installed the tool in that window, the advice is direct. OpenSourceMalware's check: run go version -m on the binary and look for a "+dirty" or vcs.modified=true line, run ovhcloud version (a clean build prints its tag, such as v0.15.0), or compare the archive's checksum with the clean checksums in v0.16.0. If you ran it, rotate credentials from a different machine: OVHcloud API keys, cloud provider credentials, SSH keys, package-manager tokens, Kubernetes configs and anything in .env files. Then remove the binary and install v0.16.0 or later.

For maintainers, the lessons are practical and cheap: turn on immutable releases, publish through a service account rather than personal accounts, limit write access for peripheral contributors, sign or attest your binaries, and enable private vulnerability reporting. For consumers, pin and verify hashes in CI. It was exactly that habit that exposed this attack: one downstream user's pinned checksum failed. v0.16.0 carries a GitHub release attestation that can be checked with gh attestation verify.

What we don't know yet

• What the payload does. OVHcloud deleted the files before they were archived, and OpenSourceMalware has not analysed the binary. Klaba's description (it retrieves secrets from disk) is the only account of its behaviour, and it has not been published where the data went.
• How the account was taken. An infostealer or a stolen token are the likeliest paths according to OpenSourceMalware; this is not confirmed.
• Whether anyone's secrets were actually stolen, and how many people downloaded the files. OVHcloud has not given download counts in the sources we found.
• Exact times. The two accounts use different time zones, and OpenSourceMalware says it could not independently confirm the 12:47 to 13:12 UTC replacement times, which come from the reporter's capture. It also notes that v0.13.0 and v0.14.0 were confirmed as modified by the reporter and OVHcloud, while for v0.11.0 and v0.12.0 the evidence is OVHcloud's statement and what assets remain.
• Scope across OVHcloud. OVHcloud says first checks show no other repository was affected, and has promised a post-mortem in the coming days.

What to watch next

Watch for OVHcloud's post-mortem and for a published analysis of the binary, which would tell users exactly which files and services to rotate. More broadly, watch whether GitHub or other ecosystems make immutable releases the default, since this attack depended on a setting that was off.

Sources

• OVHcloud CLI releases backdoored on GitHub to steal developer secrets, BleepingComputer, 20 October 2026 (reports statements by OVHcloud CEO Octave Klaba)
• OVHcloud CLI supply chain compromise: release assets replaced through a GlassWorm-hijacked contributor account, OpenSourceMalware, 20 October 2026 (timeline and analysis)
• ovh/ovhcloud-cli on GitHub, the project repository, where the issue the reporter filed is referenced by OpenSourceMalware