Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware

What Happened

An attacker used a hijacked contributor GitHub account to replace download archives on five existing releases of OVHcloud's command-line tool on Monday, October 19. The new files were a build designed to steal secrets stored on the disk of any machine that runs it, the cloud provider says. They were live on GitHub for up to 94 minutes, from 12:47 to 14:21 UTC, reaching only people who installed or updated the CLI during that window on macOS, Linux x86_64 or arm64, or Windows x86_64, via a path that checks no hash.

The source code, release tag and build pipeline were untouched: the bad build was a plain go build of a later commit uploaded onto releases published between April 14 and September 16. OVHcloud deleted the swapped archives and published a clean v0.16.0 that evening as an immutable release, whose files GitHub will not let anyone change.

Who Was Exposed

OVHcloud lists v0.11.0 through v0.15.0 as compromised and v0.10.0 as clean. On v0.15.0 the attacker replaced six files, including checksums.txt so the published hashes matched the new binaries. The same six files are gone from v0.11.0 to v0.14.0. Linux i386, Windows i386, Windows arm64 and WebAssembly builds were untouched.

You were exposed if you ran the official install script (which downloads the latest release archive and never checks a hash), downloaded an archive from the release page, ran a CI job fetching the archive without a pinned hash, or ran the CLI's own upgrade command from v0.12.0, v0.13.0 or v0.14.0 on macOS or Linux. Homebrew users were protected: the cask pinned the original SHA-256 and nothing changed in the tap. go install, source builds and the Docker image were also unaffected.

How to Tell and What to Do

A customer caught the swap using go version -m on the v0.15.0 Linux arm64 binary. The bad build carries a pseudo-version (v0.15.1-0.20261013083505-5ead8ef9b43d+dirty), commit 5ead8ef instead of 760fd72, and a -ldflags="-s -w" line that genuine releases lack. Advice that any +dirty or vcs-marked build is malicious would flag OVHcloud's own clean v0.16.0. The only published hash of a swapped file is the v0.15.0 Linux arm64 archive: SHA-256 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb.

OVHcloud founder Octave Klaba wrote that anyone affected should change every secret stored on the disk, since the CLI keeps OVHcloud API credentials in ~/.ovh.conf. If you ran a swapped build or cannot tell, treat every secret readable from that machine as exposed and rotate it from a different machine, then remove the binary and install v0.16.0. Updating replaces the program but does not revoke a key already copied. OVHcloud has not said which files the binary reads, where it sends them, or how many copies were downloaded; no copy has been analyzed in public, and a postmortem is promised.

How It Happened

Anyone with write access to a GitHub repository can replace release files unless immutability is enabled; OVHcloud had not enabled it, and Klaba said the problem stemmed from that. The option is now on and the pipelines were not affected. The uploads came through the account of a contributor whose merged work is in OVHcloud's documentation repository. OpenSourceMalware ties the account to GlassWorm, the campaign hiding code in invisible Unicode characters and fetching stages from a Solana wallet memo, noting four personal repositories were force-pushed in March with such a loader. Whether the same actor did both is "our inference," the researchers wrote, and nothing from the October binary has been tied to GlassWorm.

Sources: The Hacker News