OVHcloud CLI Compromised: How to Check If You’re Affected

If you downloaded or updated the OVHcloud CLI between 12:47 and 14:21 UTC on October 19, 2026, treat that machine as exposed. The OVHcloud CLI was compromised for those 94 minutes: an attacker swapped the GitHub release files for versions v0.11.0 through v0.15.0 with a build that steals credentials from disk. OVHcloud’s advice is to change every secret stored on the affected machine and move to the clean v0.16.0 release.

Below: who’s at risk and who isn’t, the fastest way to check a machine, which credentials to rotate, and how to verify the new release before you install it.

How the OVHcloud CLI was compromised

The OVHcloud CLI (the ovhcloud command, published in the ovh/ovhcloud-cli GitHub repository) is the official command-line tool for managing OVHcloud servers, domains and cloud projects. On Monday, October 19, someone used the GitHub account of one contributor to replace download archives attached to five existing releases. No new version number appeared, and the download links didn’t change, so anyone fetching those versions got the replacement files.

A customer spotted the swap because their CI job pinned the SHA-256 hash of the Linux arm64 archive and the hash no longer matched. They reported it in a public GitHub issue, since the repository had no private reporting channel. OVHcloud deleted the swapped files at 14:21 UTC and published v0.16.0 at 17:16 UTC as an immutable release with a signed attestation. Founder Octave Klaba said the attack hit only this one repository and left the release pipeline itself alone.

OVHcloud’s postmortem counts about 250 downloads of the malicious files. Each copy contained the real CLI, recompiled with a hidden stealer that copies AI coding-tool data (VS Code, Cursor, Continue, Sourcegraph Cody, OpenCode, Hermes and the Claude agent’s config folder), AWS, Google Cloud and Azure credentials, Docker, Kubernetes and npm configs, DigitalOcean doctl settings, SSH keys, Terraform credentials, .netrc and your global Git config. It packs them into an archive and uploads it to 45.32.148.174, using Solana RPC calls as part of the exfiltration.

As for the root cause, OVHcloud traced it to a malicious VS Code extension, color-picker-universal 2.8.91, that the developer installed on a personal MacBook on October 20, 2025. The attacker later used keys stolen from that machine to replace the releases. OVHcloud says the attack didn’t reach its internal CI/CD platform, which doesn’t run on GitHub.

Which OVHcloud CLI versions and platforms were compromised

Item	Status
v0.11.0, v0.12.0, v0.13.0, v0.14.0, v0.15.0	Release files replaced on Oct 19
v0.10.0	Clean
v0.16.0 (released Oct 19, 17:16 UTC)	Clean, immutable, signed
macOS x86_64 and arm64, Linux x86_64 and arm64, Windows x86_64	Archives replaced
Linux i386, Windows i386, Windows arm64, WebAssembly	Not changed
checksums.txt on each affected release	Replaced to match the bad files

The last row matters most. Because the attacker rewrote checksums.txt too, an archive and a checksum downloaded from the same release page would match each other even though both were malicious. A matching checksum from that page proves nothing for this window.

Did the compromised OVHcloud CLI reach your machine?

Installing one of those version numbers isn’t enough on its own. What counts is when you downloaded the file. You were likely exposed if, between 12:47 and 14:21 UTC on October 19, you did any of the following:

• Ran the official install script, which doesn’t check hashes.
• Downloaded an archive by hand from the GitHub release page of v0.11.0 to v0.15.0.
• Ran a CI job, Dockerfile or provisioning script that pulled a release archive without a pinned hash.
• Ran the CLI’s built-in upgrade on macOS or Linux after installing it by script or by hand.

You were most likely not exposed if you installed before 12:47 UTC that day and didn’t update during the window, built from source or used go install, or pulled the Docker image, which The Hacker News says was last pushed on September 21.

Homebrew is the one point where reports differ. The Hacker News says the Homebrew cask pinned the original SHA-256 hashes, so a swapped archive would have failed the check. OpenSourceMalware lists brew install and brew upgrade as possible exposure routes. If you ran either during the window, run the checks below anyway.

For reference, 12:47 to 14:21 UTC is 8:47 to 10:21 a.m. in New York and 13:47 to 15:21 in London.

How to check if the compromised OVHcloud CLI ran on your machine

Start with the quickest test, from OVHcloud’s advisory. Every time the malicious build runs, it creates a folder named envchecker- followed by nine or ten digits in your temp directory, and it never deletes it. On macOS or Linux, run ls -d ${TMPDIR:-/tmp}/envchecker-*; on Windows, run dir %TEMP%\envchecker-* in Command Prompt. If a folder turns up, the stealer ran on that account, so skip to the rotation steps below.

Next, inspect the binary itself without executing it. OVHcloud wrote the CLI in Go, so the binary carries its own build information. You can read it with the Go toolchain without executing the file:

go version -m ./ovhcloud

Look at two lines in the output. In the malicious v0.15.0 Linux arm64 build, the module version read v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, a pseudo-version from an untagged commit dated October 13, and the commit was 5ead8ef. The real v0.15.0 tag points to commit 760fd72. A build that references 5ead8ef is the swapped one.

Don’t rely on the word “dirty” alone. The Hacker News notes that the clean v0.16.0 build also reads v0.16.0+dirty, so the commit hash is the stronger signal.

If you still have the downloaded archive, compare its SHA-256 with a value you recorded before October 19, such as a hash pinned in your CI config or lockfile. The one published malicious hash is for the v0.15.0 Linux arm64 archive: 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb. The original archive’s hash was 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0. OVHcloud’s advisory also lists MD5 hashes for the malicious binaries themselves: macOS arm64 6f2f086239f3d88eb2750e871901927d, macOS x86_64 347e65eb7f2d78d1c6872690272a6cc3, Linux arm64 01f57206d37c28cf711677f612052913, Linux x86_64 301bff0b51980b9e76c93633e7cfd3bd and Windows x86_64 6a3cf153338c416169cda2fe704c8848. Run md5sum ./ovhcloud (Linux), md5 ./ovhcloud (macOS) or certutil -hashfile ovhcloud.exe MD5 (Windows) to compare.

Also check download timestamps in your shell history, CI logs, package caches and container build logs. On macOS, OpenSourceMalware suggests looking for a file named ~/init.json, which it describes as a marker left by the loader linked to the same account.

What to do if you ran an affected build

1. Keep the file, don’t run it. Move it somewhere nothing can execute it if you or your security team want to inspect it later.
2. Rotate secrets from a different, clean machine. Start with your OVHcloud API application key, application secret and consumer key, then anything else stored in ~/.ovh.conf or environment variables.
3. Go wider than OVHcloud. Treat every secret readable by that user account as exposed: SSH keys, other cloud credentials, Kubernetes configs, .env files, and tokens in .npmrc, .pypirc or .netrc.
4. Check the logs. Review OVHcloud account activity, SSH logins and any other service the rotated keys could reach for access you don’t recognize since October 19.
5. Remove the old binary and install v0.16.0 from the official release page, then verify it as shown below.

Because the stealer also copied AI coding-tool databases, revoke any API keys those tools store (OpenAI, Anthropic, Cursor and similar) and assume someone read your chat histories. Deleting the binary doesn’t undo anything it already read. Rotation is the step that protects you. If your build servers or CI runners pulled an affected archive, rotate the secrets those runners hold too, including deploy keys and registry tokens.

How to verify v0.16.0 before installing

OVHcloud published v0.16.0 with a release attestation, which ties the files to the release in a way a later file swap can’t fake. With the GitHub CLI installed, check a downloaded file against the release:

gh release verify-asset v0.16.0 ./your-downloaded-archive -R ovh/ovhcloud-cli

Replace the path with the archive you downloaded. In CI, pin the SHA-256 of each archive you fetch and fail the job if it changes. That one setting is what caught this attack.

The same lesson applies to other tools you install from GitHub release pages. The OpenCode breach also put developer API keys at risk, and our guides to the AOMEI Backupper malware check and the Rank Math Pro 3.0.123 malware walk through similar “is my copy the bad one” checks.

FAQ

Is the OVHcloud control panel or my hosting affected?

Nothing reported so far points to that. OVHcloud says the attack hit one GitHub repository and not its build pipelines. The risk is to machines that ran a swapped CLI binary and the secrets stored on them.

I installed v0.15.0 in September. Am I at risk?

Not from this incident, if you didn’t reinstall or upgrade between 12:47 and 14:21 UTC on October 19. The attacker replaced the files on that day, not when the versions first came out. Moving to v0.16.0 is still sensible.

Is the compromised OVHcloud CLI linked to GlassWorm?

Yes, according to OVHcloud’s own postmortem. The VS Code extension that stole the developer’s keys made calls to a Solana wallet that researchers already tie to the GlassWorm threat actor, and the same wallet appeared when attackers hit the developer’s personal repositories in March 2026.

Should I switch to version v0.10.0?

The Stack reported v0.10.0 as clean, but v0.16.0 is newer, clean, and the only release with a signed attestation. Use v0.16.0 unless you have a specific reason to stay on an older version.

Do this today

First, look for an envchecker- folder in your temp directory. Then search your CI logs and shell history for any OVHcloud CLI download on October 19, run go version -m on any binary installed that day, and rotate keys from a clean machine if you find one built from commit 5ead8ef. Then pin hashes in every pipeline that pulls release archives.

Related guides

• Zeabur Shutting Down: What to Do Before December 1
• DreamHost Password Reset: What to Do After the Incident
• AGENTS.md Attack: Keep AI Coding Agents Out of Downloads

Sources

• OVHcloud: ovhcloud-cli security incident advisory and postmortem, GHSA-862f-55f5-vmvw (October 2026)
• The Hacker News: Hackers hijack five OVHcloud CLI releases to distribute secret-stealing malware (October 2026)
• The Stack: OVHCloud repository hacked, customer reports incident
• Gridinsoft: OVHcloud CLI compromise, old releases, replaced files
• OpenSourceMalware: GlassWorm hacks OVH Cloud’s CLI tool