OVHcloud CLI Releases Compromised to Distribute Malware

They were live on GitHub for up to 94 minutes — from 12:47 to 14:21 UTC on Monday, October 19 — during which time attackers used a hijacked contributor account to swap five OVHcloud CLI release archives for a build that steals secrets from any machine that runs it, the company and investigators say.

GitHub releases, immutability, and how the files were replaced

Anyone with write access to a GitHub repository can delete and re-upload files attached to an existing release; the download URL does not change unless release immutability is enabled. OVHcloud had not enabled the immutability option, which has been generally available since October 2025. Because the setting was not active, a user with appropriate permissions could modify published release files directly on GitHub without the company's CI/CD pipeline running.

The attacker uploaded plain go build binaries — a build of a later, untagged commit — directly onto release pages that had been published between April 14 and September 16. OVHcloud's source code, release tags, and build pipelines were not modified; the swapped files were uploaded straight onto existing releases.

Who and what were exposed

OVHcloud lists five releases as compromised: v0.11.0 through v0.15.0. The vendor identifies v0.10.0 as clean and published a clean, immutable v0.16.0 that evening.

• The swapped archives affected macOS x86_64 and arm64, Linux x86_64 and arm64, and Windows x86_64 on the v0.15.0 release; the same six files were removed from v0.11.0–v0.14.0 as well.
• The attacker did not touch Linux i386, Windows i386, Windows arm64, or WebAssembly builds; the five old releases now offer only the four archives the attacker did not modify.
• People exposed are those who installed or updated the OVHcloud CLI during the window by running the official install script (curl -fsSL https://raw.githubusercontent.com/ovh/ovhcloud-cli/main/install.sh | sh), downloaded an archive from the affected GitHub release pages, fetched an archive in CI without a pinned hash, or used the CLI’s own upgrade command on a macOS or Linux machine where the tool had been installed by the script or by hand.
• Install paths that were not affected include Homebrew (its cask pinned the original SHA-256 and would have refused the swapped files), go install or building from source (the v0.15.0 tag still points to commit 760fd72), and pulling the Docker image (the latest tag had been pushed on September 21 and was not rebuilt).

How the malicious build was identified

A customer who detected the swap inspected the new Linux arm64 binary with go version -m (a read-only query) and posted the result to a public GitHub issue. Three markers distinguish the swapped build from an authentic release:

• The module line in the malicious binary read v0.15.1-0.20261013083505-5ead8ef9b43d+dirty — a pseudo-version for an untagged commit from October 13 — whereas genuine releases carry their tag number (OVHcloud's clean v0.16.0 build reports v0.16.0+dirty).
• The malicious build recorded commit 5ead8ef, not 760fd72, the commit the v0.15.0 tag points to.
• A -ldflags="-s -w" line was present; OVHcloud's release pipeline normally builds with a version flag that Go leaves out of the recorded flags, so a genuine release shows no -ldflags line.

Beware: circulating advice that any binary marked +dirty or carrying vcs lines is automatically malicious would also flag OVHcloud's own clean v0.16.0; The Hacker News confirmed the clean v0.16.0 binary reports v0.16.0+dirty, vcs.modified=true and its commit.

The only published SHA-256 of a swapped file is the v0.15.0 Linux arm64 archive: swapped archive SHA-256 is 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb; original archive SHA-256 is 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0.

OVHcloud's response and the public timeline

OVHcloud deleted the swapped files at 14:21 UTC after a public issue exposed the problem; that issue was filed at 13:50 UTC according to OpenSourceMalware’s timeline. OVHcloud published a clean, immutable v0.16.0 at 17:16 UTC under its ovh-cds account with a signed tag and a release attestation.

Founder Octave Klaba posted on X advising anyone affected to change every secret stored on disk. OVHcloud has not published which files the malicious binary read, where it sent any data, or how many copies were downloaded. The company has promised a detailed postmortem.

What this means for technologists, CI teams, and open-source maintainers

• Technologists and security teams: Treat any machine that ran a swapped build as potentially exfiltrated. OVHcloud and external investigators advise rotating every secret readable from the machine and doing rotations from a separate, uncompromised system.
• CI teams and integrators: Pinning SHA-256 hashes in CI caught this incident — a customer's job that pinned the Linux arm64 SHA-256 failed and triggered the public report. The attack underscores the risk of fetching binary artifacts from release pages without pinned hashes or immutability.
• Open-source maintainers: Enabling GitHub release immutability and publishing signed release attestations are concrete mitigations; OVHcloud enabled immutability after the incident, and its v0.16.0 carries a signed attestation.

Open questions remain in the public record: OVHcloud has not disclosed how the contributor account was compromised, no swapped archive has been publicly analyzed, and investigators have not tied the October binary to the GlassWorm tooling beyond linking the shared account to prior force-push activity. OVHcloud's promised postmortem will be the next fact to watch — and for teams that relied on the affected releases, the immediate task is rotating secrets and verifying any installed archives against the clean v0.16.0 release.

Original report: The Hacker News — Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware