Threat intel
OVHcloud CLI releases swapped for a secret stealer
A hijacked developer account replaced binaries in five OVHcloud CLI releases for 94 minutes on October 19. Who is exposed, what to check and what to rotate.
On October 19, 2026, someone using an OVHcloud developer's GitHub account replaced the downloadable binaries in five existing releases of the OVHcloud command-line interface (CLI), v0.11.0 through v0.15.0, with a build that steals secrets from disk. The swapped files were live from 12:47 to 14:21 UTC, about 94 minutes, until a customer reported them and OVHcloud deleted them.
If you or a CI runner downloaded the CLI for macOS, Linux (x86_64 or arm64) or Windows x86_64 in that window, treat every secret on that machine as stolen. v0.10.0 and the new v0.16.0 are clean, and so are copies installed before 12:47 UTC that were not updated during the window.
How it works
A GitHub release is a tag plus a set of downloadable files, called assets. Anyone with write access to the repository can delete an asset and upload a new file under the same name. The download URL does not change, so install scripts, curl lines in CI jobs and update commands keep fetching the same address and get the new file without any sign that something moved.
That is what happened here. The attacker never touched the source code, the tags or the build pipeline. According to The Hacker News, the release workflow never ran: the malicious build was compiled outside OVHcloud's CI/CD and uploaded straight over the old assets. OVHcloud's CEO Octave Klaba said a user with the right permissions "could directly modify existing releases on GitHub without any checks from our CI/CD", which bypassed the unit tests, functional tests and CVE scanning that normal releases go through.
OVHcloud names one root cause: GitHub release immutability was not enabled. With immutable releases, assets cannot be changed or deleted once a release is published, and the tag cannot be moved, so the swap would have failed. OVHcloud has now turned it on across the organisation.
What the attacker did, and who it was
OVHcloud's advisory says the stealer is the genuine CLI with an extra Go module added. Each time the binary runs, it copies sensitive files into a new temporary folder, archives it and sends it out through a relay that uses Solana blockchain RPC endpoints. The advisory lists what it collects:
- AWS (including S3), Google Cloud, Azure, DigitalOcean (
doctl) and Terraform credentials - Docker and Kubernetes configuration
- SSH keys, global Git config,
.netrcand npm config - Configuration and databases from VS Code, Cursor, Continue, Sourcegraph Cody, OpenCode, Hermes and Claude
The CLI itself keeps OVHcloud API keys in ~/.ovh.conf or environment variables, so those belong on the list too.
On how the account was taken, OVHcloud's post-mortem says the developer installed a malicious VS Code extension, color-picker-universal 2.8.91, on a personal MacBook in October 2025. It registered a persistent NodeJS service and talked to a Solana wallet linked to GlassWorm, a group that has targeted developers since early 2025. OVHcloud says the releases were replaced using stolen credentials rather than from that laptop, and its corporate laptop is not known to be compromised.
Researchers at OpenSourceMalware found that four of the same account's personal repositories were force-pushed in March 2026 with a hidden loader that reads its next stage from Solana transactions, using a wallet already known as a GlassWorm indicator. They describe the link between that and the October swap as "our inference": no copy of the October binary was kept for them to compare. Treat the GlassWorm attribution as likely but unconfirmed.
The swap was caught by a customer whose CI job pins the SHA-256 hash of the Linux arm64 archive. The hash check failed, and the customer opened a public GitHub issue at 13:50 UTC.
What to do
Find out whether you downloaded it. Search for any install or update of ovhcloud on October 19 between 12:47 and 14:21 UTC (14:47 to 16:21 in Paris). Look at:
- shell history and install logs on developer laptops, including runs of the official install script and the CLI's own upgrade command
- CI job logs for any pipeline that downloads the CLI from the GitHub release page without a pinned hash, including self-hosted runners that cache tools
- proxy or firewall logs for downloads from
github.com/ovh/ovhcloud-cli/releases
Users who built from source, used go install or pulled the official Docker image were not exposed. Reports differ on Homebrew: OpenSourceMalware's write-up lists the Homebrew cask as an affected path, while The Hacker News found the cask pinned the original hash and saw no change to it. If you installed through Homebrew in the window, check the binary anyway.
Check the binary without running it. OVHcloud's advisory publishes an MD5 hash for each swapped binary (Darwin arm64 and x86_64, Linux arm64 and x86_64, ovhcloud.exe). Run md5sum on Linux, md5 on macOS or Get-FileHash -Algorithm MD5 in PowerShell and compare. The advisory also says the stealer leaves a folder named envchecker- followed by 9 or 10 digits in the system temp directory and never deletes it; finding one means it ran. Keep a copy for investigation before cleaning up, and check DNS and proxy logs for the Solana RPC hosts and the exfiltration IP listed in the advisory.
Rotate first, then reinstall. Updating the CLI does not revoke keys that were already copied. From a clean machine, rotate cloud access keys, SSH keys, Kubernetes and Docker registry credentials, Git and npm tokens, OVHcloud API keys and any AI tool tokens on the affected host. For a CI runner, rotate every secret the runner could read, not only the ones the job used. Then delete the binary and install v0.16.0, which OVHcloud published as an immutable release with a signed tag. Check it with gh release verify-asset v0.16.0 <file>.
Locking your own releases
If you ship binaries through GitHub releases, enable immutability now. For one repository, open Settings, scroll to Releases and enable release immutability. For a whole organisation, open the organisation's Settings, go to Repository, then General, and under Releases change "No policy" to All repositories. It only protects releases published after you switch it on, so cut a fresh release afterwards and point users at it.
On the consuming side, a checksum fetched from the same release page proves little when the attacker can rewrite that page. Pin the expected hash in your pipeline, as the customer who caught this did, or check provenance with gh release verify <tag> and gh release verify-asset <tag> <file>, which validate the attestation GitHub creates for immutable releases. For the people who can publish, review who holds write access to release repositories, and treat developer workstations and editor extensions as part of the supply chain.
We review release pipelines, CI secrets and repository permissions in our platform and cloud engineering work, and look for stolen-credential activity in security operations. If you want to know whether a tool you depend on could be swapped the same way, open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: OVHcloud advisory GHSA-862f-55f5-vmvw, Help Net Security, The Hacker News, SecurityWeek, The Stack, GitHub Docs: immutable releases, GitHub Docs: verifying a release.