---
title: "OVHcloud CLI Supply Chain Swap: Rotate Secrets Now"
description: "OVHcloud CLI versions v0.11.0 through v0.15.0 were replaced with a secret stealing build on October 19, 2026. Who is affected, what to rotate, and the governance lesson."
url: https://policycortex.com/blog/ovhcloud-cli-supply-chain-secrets
sealed: 2026-10-22
register: blog/ovhcloud-cli-supply-chain-secrets
records: 3
digest: sha3:b358da28ee99d153302757b54971fc03203600361c3ed2b9716dacc65c5585fe
---

# OVHcloud CLI Releases Were Swapped for a Secret Stealing Build

Resources / Blog

Advisory GHSA-862f-55f5-vmvw says a compromised developer account replaced OVHcloud CLI release binaries for 94 minutes on October 19, 2026. About 250 downloads happened. Rotate secrets if you downloaded then.

Leonard Esere · Sealed 2026-10-22 · Reading time 5 min

Filed under: [OVHcloud](https://policycortex.com/blog/tags/ovhcloud), [supply chain](https://policycortex.com/blog/tags/supply-chain), [GitHub](https://policycortex.com/blog/tags/github), [secret theft](https://policycortex.com/blog/tags/secret-theft), [incident response](https://policycortex.com/blog/tags/incident-response), [NIST 800-171](https://policycortex.com/blog/tags/nist-800-171)

**Summary**

- A compromised developer account replaced OVHcloud CLI binaries for v0.11.0 through v0.15.0 on October 19, 2026.
- The bad files were live from 12:47 to 14:21 Coordinated Universal Time. OVHcloud reports about 250 downloads.
- The Hacker News reports the checksums.txt file on v0.15.0 was also swapped. Checksum checks alone would not catch it.
- OVHcloud released v0.16.0 as an immutable release with a signed tag. Affected users should rotate local secrets.

## A trusted download turned hostile

OVHcloud sells a command line interface (CLI) tool. Admins use it to manage cloud services from a terminal.

On October 19, 2026, that trusted download changed. An attacker replaced the release binaries with a secret stealing build.

The advisory is [GHSA-862f-55f5-vmvw](https://github.com/advisories/GHSA-862f-55f5-vmvw). It carries no Common Vulnerabilities and Exposures (CVE) number.

This was a supply chain compromise. It was not a flaw inside the CLI code itself.

## What the advisory says happened

OVHcloud says a compromised developer GitHub account did the swap. The account replaced existing release assets on October 19.

The bad files were live for about 94 minutes. The window ran from 12:47 to 14:21 Coordinated Universal Time (UTC).

Those times match the advisory timeline in Paris time. The advisory lists 14:47 to 16:21 at UTC plus two hours.

OVHcloud reports about 250 downloads in that window. Only users who installed during that window are affected.

Downloads before October 19 are unaffected, OVHcloud says. Source code was not affected. The build chain was not affected.

No other repository projects were affected. OVHcloud states that finding in the advisory itself.

## Which versions and files were hit

The affected releases are v0.11.0 through v0.15.0. Versions at or below v0.10.0 are not affected.

Versions at or above v0.16.0 are not affected. The advisory lists those clean ranges clearly.

The advisory lists targeted files on the workstation. They include cloud credentials for three major cloud providers.

They also include Secure Shell (SSH) keys. They include Docker, Kubernetes, Terraform, and npm configuration files.

The list also covers artificial intelligence (AI) tool data. That includes Claude, Cursor, VS Code, and OpenCode stores.

The bad build copied files into a temp folder. The folder name starts with envchecker, OVHcloud says.

Finding that folder is one exposure check. OVHcloud also lists MD5 hashes of the bad binaries.

Do not run a suspect binary to check it. Compare hashes without running it, OVHcloud advises.

## The checksum lesson

The Hacker News reports one more detail. On v0.15.0, six files were replaced.

Five were platform archives for macOS, Linux, and Windows. The sixth was the checksums.txt file itself.

So the published hashes matched the bad binaries. A checksum hosted beside the binary is not proof.

That point matters beyond this one incident. Proof must live somewhere the attacker cannot rewrite.

Independent signatures and pinned hashes serve that role. A file beside the download does not.

## What OVHcloud changed

OVHcloud removed all malicious binaries at 14:21 UTC. It suspended the compromised developer account.

It reviewed accounts with write access. It also scanned its other GitHub repositories.

The root cause was release immutability. The repository was not set to lock published releases.

OVHcloud says that setting is now corrected. The same setting was applied across its repositories.

OVHcloud then released version v0.16.0 that evening. It is an immutable release with a signed tag.

## What to do this week

Find every workstation that installed the CLI. Check install dates against the October 19 window.

If a download falls inside the window, act. Treat every reachable local secret as exposed.

Rotate cloud credentials from a clean machine. Rotate SSH keys and AI tool keys too.

Delete the compromised binary after hash checks. Then install v0.16.0 from the immutable release.

Record each rotation with a date. Keep the advisory reference beside each record.

## The governance lesson

You cannot govern tools you never inventoried. This CLI reached cloud credentials and SSH keys.

Yet many tool inventories list only servers. Developer workstations often sit outside that list.

Inventory every CLI that touches your boundary. Record its source, version, and install path.

Pin versions where your process allows it. Verify new downloads against independent proof.

PolicyCortex does not distribute or clean CLI tools. This article covers evidence and governance only.

## Sources

- OVHcloud security advisory [GHSA-862f-55f5-vmvw](https://github.com/advisories/GHSA-862f-55f5-vmvw), ovh/ovhcloud-cli repository. Affected versions, timeline, download count, targeted files, and the v0.16.0 fix.
- "Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware," The Hacker News, October 2026. https://thehackernews.com/2026/10/hackers-hijack-five-ovhcloud-cli.html Checksums.txt swap and platform detail.
- Original diagram by PolicyCortex.

## Next step

Want developer tool inventories tied to your compliance evidence? See how [PolicyCortex](https://policycortex.com) collects that evidence.

**Questions on this record**

**Q: Which OVHcloud CLI versions were swapped?**
A: Versions v0.11.0 through v0.15.0. The advisory says downloads before the October 19 window are unaffected, and v0.16.0 is clean.

**Q: How long were the bad binaries live?**
A: About 94 minutes on October 19, 2026, from 12:47 to 14:21 Coordinated Universal Time. OVHcloud reports about 250 downloads in that window.

**Q: Why did checksum checks not catch the swap?**
A: The Hacker News reports the checksums.txt file on v0.15.0 was replaced too. The published hashes matched the bad binaries.

**Q: What should affected users do?**
A: Treat local secrets as exposed and rotate them. Delete the bad binary, then install v0.16.0, the immutable release with a signed tag.

## Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages and one architecture page.

- **proof.state**: [Proof of State](https://policycortex.com/proof/state). What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
- **proof.change**: [Proof of Change](https://policycortex.com/proof/change). Who or what altered the environment, under what authority, with before and after state hashes.
- **proof.agency**: [Proof of Agency](https://policycortex.com/proof/agency). What a machine was permitted to do before it acted, what it did, and what would have stopped it.
- **architecture**: [Architecture](https://policycortex.com/architecture). How the chain is built and where it lives: inside your tenant, with no egress of evidence.

### Further reading in this register

| Published | Entry | Reading |
|---|---|---|
| 2026-10-22 | [Eight CA Keys Compromised: What the eMudhra Incident Teaches About Trust](https://policycortex.com/blog/emudhra-ca-compromise-certificate-trust): Private keys for eight eMudhra intermediate certificates were weak enough to recover from public data. Mozilla, Chrome, Apple, and Microsoft rushed to block them. The trust system worked this time. Your certificate inventory may not. | 5 min |
| 2026-10-22 | [Stolen Keys, Signed Commands: The UpdraftCentral Supply Chain Backdoor](https://policycortex.com/blog/updraftcentral-key-compromise-supply-chain): Attackers stole TeamUpdraft's UpdraftCentral keys and pushed backdoors to WordPress sites as properly signed commands. No plugin flaw was needed. Patchstack rates the impact 9.8. | 5 min |
| 2026-10-21 | [You Cannot Patch What You Forgot: PHP2Shell, LiteLLM, and Governance](https://policycortex.com/blog/php2shell-litellm-governance-proof): Two failures on October 21, 2026 made the same gap public. One hid in a language runtime. One hid in a trusted release. Governance means you can prove what runs, what version, and what you fixed. | 6 min |

Verify the record this entry describes. [Request Access](https://app.policycortex.com/auth?mode=request-access) · [Book a call](https://policycortex.com/book)

Dates of record

- **Published**: 2026-10-22
- **Last updated**: Unchanged since sealing
- **Author**: Leonard Esere
- **Record**: https://policycortex.com/blog/ovhcloud-cli-supply-chain-secrets

## Register colophon

| Seq | Label | SHA3-256 | Prev |
|---|---|---|---|
| REC 0000 | HEAD | 1db14616de94 | eba37a0bf81a |
| REC 0001 | BODY | 87a7fcdf856f | 1db14616de94 |
| REC 0002 | RELATED RECORDS | b358da28ee99 | 87a7fcdf856f |

Head sha3:b358da28ee99d153302757b54971fc03203600361c3ed2b9716dacc65c5585fe. Each digest is SHA3-256 over the previous digest, the register key, the record label, and the record copy; a second party can recompute it from this document.
