OVHcloud CLI Hack: Account Hijacked Since March

OVHcloud’s official command-line tool was booby-trapped for about 94 minutes on Monday, 19 October 2026, after an attacker used a developer’s GitHub account to replace release downloads with builds carrying a secrets-stealing binary, founder Octave Klaba said on X. Versions v0.11.0 through v0.15.0 of the OVHcloud CLI were affected. Researchers now say the account behind the swap had been hijacked since at least March, and they link it to the GlassWorm malware campaign.

Klaba said the tampered files went live at 14:47 Paris time (12:47 UTC) and were blocked at 16:21 (14:21 UTC) after a customer reported them. The added binary was built to collect secrets stored on the machine’s disk. “The quality of the binary is poor but it can go all the way,” Klaba wrote. He told anyone affected to change every secret on their disk. Versions v0.10.0 and the new v0.16.0 are clean.

In a follow-up post late on Monday, Klaba said GitHub’s release immutability option had not been switched on for the repository. That allowed an account with the right permissions to change existing releases directly on GitHub, bypassing OVHcloud’s CI/CD pipeline. He said the pipelines themselves, including their testing and CVE detection stages, were not affected. OVHcloud has since enabled immutability and considers the incident resolved.

How the swap worked and how it was caught

The alarm came from a GitHub issue filed by a user whose CI pipeline pins the SHA-256 hash of the CLI’s Linux arm64 archive and suddenly started failing. The attacker did not publish a new version. Instead, they replaced files on releases that had been published between April and September.

On each release, the macOS, Linux x86_64 and arm64, and Windows x86_64 archives were swapped, along with the release’s checksums.txt file. The i386, Windows arm64 and WebAssembly builds were left untouched.

Because the checksum files were rewritten, too, anyone verifying a download against the release page would have seen a match. Only a hash recorded before the swap caught it.

The reporter’s inspection of the binary’s build metadata showed a plain local build from a 13 October commit with uncommitted changes, not the output of OVHcloud’s release pipeline. OpenSourceMalware, a community threat-intelligence group, reconstructed the timeline from GitHub’s server-side records.

It found that no release workflow ran during the window and that the files were uploaded through the ordinary GitHub Releases API, most likely by a script, in about 25 minutes. The account used belonged to a contributor whose merged work sits in OVHcloud’s documentation repositories. It was not a public member of the organisation, but it had write access to the CLI repository.

OVHcloud maintainer Romain Beuque said that all affected binaries were deleted at 16:21. The company then shipped v0.16.0, published at 17:16 UTC under its ovh-cds service account, with a signed tag and a release attestation. “This release is immutable, so the assets attached to it can be trusted,” Beuque wrote.

The GlassWorm link

OpenSourceMalware found that four of the contributors’ personal repositories were force-pushed on 5 and 6 March 2026 with amended commits. Each added a hidden loader that decodes invisible Unicode characters and fetches its next stage from the memo field of a Solana wallet’s transactions. That wallet appears on public GlassWorm indicator lists. GlassWorm is the campaign that has hit VS Code, OpenVSX, npm and GitHub since late 2025, and its ForceMemo wave pushed malware into hundreds of repositories with stolen GitHub tokens in March.

The researchers stress that tying the March compromise to the October release swap is their own inference, resting on the shared account. Nobody has publicly analysed the CLI payload itself, because OVHcloud deleted the swapped files before any copy was preserved.

Who was affected and what to do

Exposure was limited to people who installed or updated the CLI on macOS, Linux x86_64 or arm64, or Windows x86_64 between 12:47 and 14:21 UTC on 19 October, via a path that did not check hashes. That covers the official install script, which has never verified checksums. It also covers direct downloads from the release page, CI jobs fetching the release URL without a pinned hash, and the CLI’s built-in upgrade command on script or manual installs of v0.12.0 to v0.14.0. Copies installed before the window and not updated since are the originals.

Builds from source with go install and the ovhcom/ovhcloud-cli Docker images were not affected. The image was last pushed on 21 September. Homebrew is the one route the researchers disagree on. OpenSourceMalware listed it as exposed. The Hacker News reported that the tap’s cask pinned the original archive hashes throughout the window, so Homebrew would have refused the swapped files.

Anyone who ran a swapped build, or cannot tell whether they did, should treat every secret on that machine as exposed. They should rotate those secrets from a different computer before deleting the binary and installing v0.16.0. The CLI stores OVHcloud API credentials in ~/.ovh.conf or in environment variables, so OVHcloud application keys, consumer keys and OAuth client secrets come first, followed by SSH keys, Kubernetes configs, cloud credentials, Git tokens and .env files. Updating replaces the program but does not revoke a key that has already been copied.

The incident follows a March 2026 BreachForums claim of an OVHcloud data breach, which Klaba disputed at the time. Nothing links the two events.

OVHcloud has not yet said how the contributor’s credentials were stolen, which files the binary reads, where it sends them, or how many copies were downloaded during the window. The company says a detailed post-mortem will follow in the coming days.