For roughly an hour and a half on Monday, anyone fetching the official OVHcloud command-line tool from GitHub could have been handed a build designed to harvest secrets from their disk. The window was short, but the clean-up for affected machines is not.
What happened
On 19 October 2026, an attacker used a compromised GitHub account belonging to a legitimate OVHcloud contributor with write access to the ovh/ovhcloud-cli repository and replaced the downloadable binaries on five releases that had already been published: v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0. The substitute build was designed to collect secrets from the host’s disk. OVHcloud founder and CEO Octave Klaba disclosed the compromise on X, describing the malware’s quality as poor but warning that it could still do real damage.
All times in this article are UTC; OVHcloud’s statements used Paris time. The swapped files went live at 12:47 and were removed at 14:21, so they were downloadable for about 94 minutes. Klaba’s figures of 14:47 and 16:21 refer to the same window in Paris time. According to the timeline compiled by OpenSourceMalware, a community threat intelligence platform, the attacker spent around 25 minutes uploading replacement files, finishing at 13:12. A customer raised the alarm at 13:50, and OVHcloud published a clean v0.16.0 at 17:16.
The detection did not come from OVHcloud’s own controls. A customer’s CI job had pinned the SHA-256 hash of the Linux arm64 archive and started failing when the file changed. With no private reporting route on the repository, the customer opened a public GitHub issue.
The technical picture
No source code changed, the release tags still point at their original commits, and the GitHub Actions release workflow never ran. Instead, the account was used through the ordinary GitHub Releases interface to delete existing assets and upload new ones with identical names. Because GitHub release immutability was switched off on the repository, nothing prevented a user with write access from doing this, and the download URLs stayed the same. Klaba confirmed this missing setting as the root cause.
Six files were swapped on v0.15.0: the two macOS archives, both 64-bit Linux archives, the 64-bit Windows archive and checksums.txt. The same six are now missing from the other four releases. Rewriting the checksums meant anyone comparing a download against the published hashes would see a match. 32-bit, Windows on Arm and WebAssembly builds were untouched.
Exposure depends on how the tool was obtained. Users were at risk if, during the window, they ran the official install script (which has never checked hashes), downloaded an archive directly from the release page, ran an unpinned CI job against the release URL, or used the CLI’s own upgrade command from certain versions on macOS or Linux. Building from source, using go install or pulling the Docker image was safe, and so was any copy installed before 12:47 and not updated. The Hacker News examined the Homebrew tap’s history and reported that the cask still pinned the original hashes, so a Homebrew install would have errored out instead of accepting the tampered archive.
The rogue build can be identified without executing it. Running go version -m against a suspect binary reveals its build metadata: the bad build reports a pseudo-version rather than a release tag, records commit 5ead8ef instead of 760fd72 (the commit behind v0.15.0), and carries an -ldflags line that OVHcloud’s release tooling does not produce.
On attribution, OpenSourceMalware assesses that the account is linked to GlassWorm, a campaign active since late 2025 across VS Code, OpenVSX, npm and GitHub. Its evidence is that the account’s personal repositories were force-pushed in March 2026 with a hidden loader using a Solana wallet memo dead drop, a known GlassWorm hallmark. The researchers are clear that tying the October uploads to the same actor is their own inference, and no copy of the October payload has been analysed publicly.
Why it matters for UK organisations
OVHcloud is a major European cloud and hosting provider serving UK customers. Its CLI sits on administrators’ laptops and inside automation, where the most valuable credentials live. A secret stealer on a DevOps workstation does not just leak OVHcloud API keys; it can expose SSH keys, other cloud credentials, Kubernetes configs, package registry tokens and .env files.
It also fits a pattern UK SOCs should plan around: within the past week AOMEI’s update servers and a Rank Math PRO update were both tampered with. Each shows that the route software takes to users is a target in its own right.
Expert view
In my experience, most organisations treat “downloaded from the vendor’s official GitHub” as the end of the trust conversation. The attacker did not defeat signing, tests or vulnerability scanning; they simply walked around them, because the release assets were mutable and the install script trusted whatever it was given. A checksum file published alongside the binary only protects you against corruption, not against someone who can rewrite both.
The most effective control here was also the least glamorous: one customer pinned a hash in CI. When we test build estates, unpinned third-party downloads come up constantly and are usually waved through as low risk. They are not. OpenSourceMalware’s finding that the account appears to have been under hostile control since at least March also suggests any account with release rights deserves the monitoring you would give a production administrator.
Finally, rotation has to be done properly. Upgrading to v0.16.0 removes the binary but does nothing about keys that have already been copied. OpenSourceMalware advises rotating from a different, known-clean machine, which is sound practice for any stealer incident.
What to do now
- Scope exposure. Find every OVHcloud CLI install or update made on 19 October from 12:47 to 14:21 UTC through the install script, direct downloads, unpinned CI jobs or the built-in upgrade command. Check CI logs and endpoint inventories.
- Inspect suspect binaries without running them. Use go version -m and compare the recorded commit and version against the genuine release. Compare archives against the hash published by researchers for the swapped Linux arm64 file.
- Rotate everything readable on affected machines. That means OVHcloud API and consumer keys, ~/.ovh.conf, SSH keys, other cloud credentials, kubeconfigs, registry tokens and .env contents. Do it from a clean device, then hunt for use of the old credentials.
- Reinstall cleanly. Remove the tool and install v0.16.0 or later, verifying it with gh release verify-asset or the release attestation.
- Harden your own releases and intake. Enable GitHub release immutability on repositories you publish from, restrict who can upload assets, and pin hashes for third-party downloads in CI. This maps to Cyber Essentials secure configuration, user access control and malware protection.
- Treat developer workstations as privileged endpoints. Apply EDR coverage and limit long-lived secrets on disk, in line with the Cyber Essentials security update management and access control requirements.
Bottom line
A 94-minute window sounds small, but a secret stealer only needs to run once. If your teams touched the OVHcloud CLI on Monday afternoon, assume compromise until proven otherwise and rotate from a clean machine. The fix that would have stopped this was a setting nobody had switched on, and the control that caught it was a pinned hash. Both are cheap.
Sources
- BleepingComputer: OVHcloud CLI releases backdoored on GitHub to steal developer secrets
- The Hacker News: Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware
- OpenSourceMalware: GlassWorm hacks OVHcloud’s CLI tool
- IT-Connect: OVHcloud CLI binaries on GitHub were tampered with by an infostealer
