OVHcloud CLI Releases Backdoored on GitHub to Steal Developer Secrets

Compromised Maintainer Account Used to Swap OVHcloud CLI Binaries With Secret-Stealing Malware

French cloud and hosting giant OVHcloud has confirmed that five published releases of its open-source ovh/ovhcloud-cli command-line tool were tampered with on GitHub and swapped for a secret-stealing build. OVHcloud CEO Octave Klaba said the attacker hijacked the GitHub account of a legitimate project contributor — not OVHcloud's CI/CD pipeline — and used the ordinary GitHub Releases API to overwrite already-published binaries for versions v0.11.0 through v0.15.0 on October 19, 2026. The incident was only caught because a customer's own build pipeline flagged a SHA-256 checksum mismatch on the Linux arm64 archive. Researchers at OpenSourceMalware have tentatively linked the account takeover to the GlassWorm threat cluster, though that attribution remains unconfirmed.

Details

How the Attack Worked

Release tampering without touching CI/CD. OVHcloud was explicit that its build pipeline — unit tests, functional tests, CVE scanning — was never breached. No new git tag was pushed and no GitHub Actions workflow executed. Instead, the attacker used a legitimate maintainer's already-compromised GitHub credentials to call the standard GitHub Releases API and overwrite the binary assets on five existing releases, including the published checksums.txt file, so the replacement hashes matched the tampered binaries. This was only possible because GitHub's release immutability setting was disabled on the repository — a configuration gap that lets any sufficiently privileged account delete and re-upload release assets under the same version tag, entirely outside the normal build-and-test path.

Why the Customer Catch Mattered

A customer's own continuous-integration pipeline happened to pin and compare the SHA-256 fingerprint of the Linux arm64 archive against a previously known value. When that archive's hash silently changed between pulls, their build failed — and they reported it to OVHcloud. Without that external check, hash verification against the (also-tampered) published checksums file would not have revealed anything unusual, since the attacker regenerated checksums.txt to match the malicious binaries.

The Malware Payload

Klaba described the dropped binary as low in sophistication but direct in purpose: a tool built to retrieve secrets from the local disk of any machine that installed or updated the CLI during the exposure window. OVHcloud has not published the binary's exfiltration destination, the exact file paths it targets, or download counts, but the company's own guidance treats every credential present on an affected disk as compromised — not just OVHcloud API tokens.

The Longer Root Cause: How the Maintainer's Account Was Taken Over

The GitHub release tampering was the final step in a much older compromise. Independent researchers at OpenSourceMalware traced the hijacked contributor account back to early March 2026, when several of that developer's personal repositories were force-pushed with amended commits that preserved the original commit messages but quietly added a malicious preinstall.js script — the kind of npm lifecycle hook that runs automatically on npm install. The script was reportedly obfuscated using invisible Unicode variation-selector characters, decrypted a payload with AES-256-CBC, and used a Solana blockchain memo as a dead-drop channel for command-and-control — letting the operator update the payload at any time without modifying any code repository. Researchers tied the pattern, and an associated Solana wallet address, to the GlassWorm campaign that has targeted software development ecosystems since late 2025. That link is attribution by indicator overlap only: no sample of the October OVHcloud binary itself was preserved for analysis, so the connection between the two incidents has not been formally confirmed by OVHcloud.

Impact Assessment

Recommendations

For Anyone Who Installed or Updated the OVHcloud CLI on October 19, 2026

• Check your installed version: if it is v0.11.0 through v0.15.0, assume the binary was potentially malicious and upgrade immediately to v0.16.0 or later.
• Upgrading alone does not undo a prior compromise — rotate every secret that was present on disk at install/update time: OVHcloud API credentials, SSH keys, cloud provider tokens, CI/CD secrets, and any password manager or config files that were readable from that session.
• Rebuild or redeploy from a known-clean environment if the affected machine was used to sign releases, push code, or hold production credentials.

For Security and Platform Engineering Teams

• Enable GitHub release immutability on every public repository your organization maintains — this single setting is what allowed the attacker to overwrite already-published, already-tested binaries without triggering CI/CD at all.
• Do not rely solely on checksums published alongside the same release you are verifying; pin hashes externally (a separate manifest, a signed attestation, or a package registry independent of the release assets) so a compromised release cannot simultaneously tamper with its own verification data.
• Monitor for anomalous GitHub Releases API activity — asset replacement on existing tags, especially outside of a corresponding Actions run — as a first-class detection signal, not just new tag pushes.
• Review the npm lifecycle scripts (preinstall, postinstall) of contributor-maintained dependencies; a legitimate maintainer's personal projects can become the initial foothold for a takeover of accounts with access to far more sensitive repositories.

For Open-Source Maintainers

• Enforce hardware-backed MFA and short-lived tokens on any account with release or publish permissions, and treat personal-repository compromises as a possible precursor to organizational account takeover.
• Audit account activity for low-and-slow indicators like scripted commit amendments or force-pushes that preserve commit messages — a technique designed specifically to blend in with normal history.

Key Takeaways

1. Attackers compromised a legitimate OVHcloud contributor's GitHub account and used the standard Releases API — not a CI/CD or build-pipeline breach — to swap binaries on five already-published CLI versions (v0.11.0–v0.15.0).
2. The attack was only possible because GitHub release immutability was disabled, letting a privileged account silently overwrite release assets, including the checksums file, without any new tag or workflow run.
3. A customer's independent CI checksum check — not OVHcloud's own verification — caught the tampering, underscoring that self-published hashes cannot verify their own integrity if the release itself is compromised.
4. The malware's goal was straightforward secret harvesting from disk; OVHcloud has urged anyone affected to rotate all locally stored credentials, not just OVHcloud-specific tokens.
5. Researchers linked the underlying account takeover to a March 2026 npm preinstall.js compromise of the maintainer's personal repositories, tentatively tied to the GlassWorm campaign — a reminder that personal developer accounts are a viable path into organizational supply chains.
6. OVHcloud has since enabled release immutability and pulled the compromised versions; source builds, Docker images, and the v0.10.0/v0.16.0 releases were never affected.

Sources

• OVHcloud CLI releases backdoored on GitHub to steal developer secrets — BleepingComputer
• Glassworm Hacks OVH Cloud's CLI tool — OpenSourceMalware
• Hackers Compromise OVHcloud GitHub Repository to Distribute Secret-Stealing Malware — GBHackers