OVHcloud CLI compromised: affected versions and fix

On 19 October 2026, files of OVHcloud’s official CLI (the ovh/ovhcloud-cli repository) were replaced with trojanized binaries, uploaded from a developer’s GitHub account. If you downloaded the CLI that day, delete it, install v0.16.0 and treat every secret readable on that machine as exposed.

Octave Klaba, OVHcloud’s founder, announced the incident on X. I cross-checked his message against the public issue on the repository, the releases page and trade press. Here is what is established, what is still unclear, and what to do.

Table of contents

What happened

According to OVHcloud, the compromised binary was published at 2:47 pm (Paris time), then detected and blocked at 4:21 pm after a customer reported it. The announced exposure window is therefore about 94 minutes.

GitHub issue #300, opened by a user whose CI pins the SHA-256 of the archives, adds verifiable details. The assets of releases v0.13.0 to v0.15.0 were replaced between 12:47 and 13:12 UTC (2:47 to 3:12 pm in Paris), several weeks after publication. The ovhcloud-cli_Linux_arm64.tar.gz archive and the checksums.txt file were rewritten, as were the macOS and Windows archives of v0.15.0.

The key point: the Git tag v0.15.0 still points to the same commit and the Go module proxy serves the same code. The source code was not modified, only the downloadable files were. Reviewing the code or checking the tag would have found nothing. Comparing the archive hash did.

According to OVHcloud, the attacker used a developer’s GitHub account to add a binary meant to collect secrets stored on disk. The company describes its quality as mediocre, but good enough to complete its job. Initial checks found no other affected repository.

Which versions are affected?

OVHcloud lists five compromised versions, v0.11.0 to v0.15.0. The public issue only documents v0.13.0 to v0.15.0 (v0.15.0 in full, the other two partially). To be safe, treat all five as compromised. Versions v0.10.0 and v0.16.0 are clean.

Only downloads made after the files were replaced, so on 19 October, are concerned. An installation made before that day is not, unless you updated or reinstalled the same day. OVHcloud has not said whether Homebrew, the Docker image or the install script distributed the tampered files: when in doubt, follow the same procedure.

According to the issue author, installing from the Go module proxy (go install) served the original code.

What to do now

1. Find out whether you are affected

Note the installed version and the download date. Then compare the archive hash with the matching line of the release’s checksums.txt, which was restored with the original files:

sha256sum ovhcloud-cli_Linux_arm64.tar.gz
# compare with checksums.txt of the matching release

For an installed binary, Go build information allows a first triage. The binary analyzed in the issue reported a “dirty” build, meaning it was built from a modified local repository:

go version -m "$(command -v ovhcloud)" | grep -E 'dirty|vcs.modified'

No output proves nothing. When in doubt, delete and reinstall. The issue author also published the hashes of the v0.15.0 Linux arm64 archive:

original  5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0
replaced  3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb

2. Delete, then install v0.16.0

Delete the binary, install v0.16.0 and verify its hash. This release is described as immutable: GitHub no longer allows its files to be changed after publication.

3. Revoke, then reissue secrets

Deleting the binary is not enough: it may already have read your files. Treat everything your user could read on the machine as exposed:

the OVHcloud API credentials used by the CLI;
SSH keys, kubeconfig files, .env files;
AWS, GCP or Azure credentials, GitHub, npm or Docker tokens;
secrets exported in environment variables or scripts.

Revoke first, reissue second, with no overlap between the old and the new secret.

4. Audit your logs

Review how your credentials were used since 19 October, 2:47 pm: unusual API calls, new keys, instances or storage you did not create, logins from unknown addresses. OVHcloud has not published the binary’s network behavior: no domain or IP to block is known yet.

5. Fix your pipelines

If a CI job or script downloaded the CLI that day, that job’s secrets are exposed. Pin the version and the expected SHA-256: that exact safeguard is what exposed the attack.

What we still don’t know

How many people downloaded the tampered files.
Which files the binary read and how it exfiltrated them. OVHcloud promises more details on the binary analysis.
How the developer’s account was compromised, and what rights it had on the repository. The issue author asked, with no public answer so far.
The post-mortem, promised “in the coming days”.

One detail for verifiers: GitHub shows the v0.16.0 tag as signed, but flags the signing key as expired.

Trivy, tj-actions: a recurring pattern

Incident	Entry point	What was altered	Malware target
OVHcloud CLI (Oct 2026)	A developer’s GitHub account	Already published release files	Secrets on users’ disks
Trivy / TeamPCP (Mar 2026)	Personal access token exposed via a misconfigured workflow	Version v0.69.4 and dozens of action tags	CI pipeline secrets
tj-actions/changed-files (Mar 2025)	Compromised personal access token	Tags redirected to malicious code	CI pipeline secrets, printed in logs

In all three cases, it starts with a maintainer credential, and the attacker changes artifacts that users considered frozen. According to SafeDep’s analysis, the malicious Trivy version stayed online for about three hours, the same order of magnitude as OVHcloud’s 94 minutes: a short window is enough when the tool runs with high privileges.

The difference is the target. Trivy and tj-actions went after CI pipelines. Here the binary is aimed at developer and administrator workstations, which hold cloud keys, SSH keys and tokens. An infrastructure CLI is a prime target: it runs with the rights of the person who administers the cloud.

For maintainers: make this scenario impossible

Enable immutable releases. Since October 2025, GitHub can lock a release’s tag and files once published. Replacing a file of an existing version, as happened here, is then impossible.
Protect tags with rulesets that block updates, deletions and force pushes.
Limit who can publish: hardware security keys or passkeys, no long-lived classic tokens, publishing rights separated from development rights.
Publish provenance attestations, which immutable releases generate automatically, so users can verify where a file comes from.
Enable private vulnerability reporting. The issue author says they found no private channel and had to open a public issue.

For users: the right habits

Pin the version and SHA-256 in CI and scripts, as the issue author did.
Avoid unverified installs, such as a script fetched from a main branch and piped straight into a shell.
Reduce what sits on disk: short-lived credentials, a secrets vault instead of plain files.
Isolate third-party tools in a sandbox, as we explain in our article on Docker sbx and Claude Code.
Cover the basics from our 10 essential cybersecurity measures.

FAQ

Do I need to rotate my secrets if I use v0.10.0?

Not for this incident. OVHcloud says v0.10.0 is clean. Only downloads of v0.11.0 to v0.15.0 on 19 October are concerned.

Is uninstalling the CLI enough?

No. The binary looked for secrets on disk: if it ran, they may have been read. Delete the binary, then revoke and reissue the secrets.

Is the CLI’s source code compromised?

According to the issue, the v0.15.0 tag and the Go module proxy still serve the original code, and OVHcloud says no other repository is affected. The downloadable files were replaced.

Are OVHcloud services or customer data affected?

So far OVHcloud has only communicated about the CLI repository. No breach of its infrastructure or customer data has been announced in the sources I consulted.

Sources

Written on 19 October 2026 from information that is still being published. I will update it when OVHcloud releases its post-mortem.

OVHcloud CLI compromised: a secret-stealing binary shipped on GitHub