OVHcloud CLI releases backdoored on GitHub to steal secrets

An attacker used a contributor's GitHub account to replace the prebuilt binaries attached to five existing OVHcloud CLI releases — v0.11.0 through v0.15.0 — with builds that steal secrets from the host. OVHcloud founder Octave Klaba confirmed the compromise and shipped a clean, immutable v0.16.0. If you installed or upgraded the CLI during the window, treat the machine as compromised and rotate every secret on it.

OVHcloud has promised a detailed postmortem. Until then the primary account comes from Klaba's statements and the timeline built by the community threat-intel platform OpenSourceMalware, reported by BleepingComputer and The Hacker News. No CVE has been assigned.

What happened

The attacker did not touch the CI/CD pipeline or the source. GitHub's release-immutability setting was off, so a sufficiently privileged account could overwrite the archives already attached to published releases without passing any checks. On v0.15.0 the attacker replaced six files — the macOS x86_64 and arm64 archives, the Linux x86_64 and arm64 archives, the Windows x86_64 archive, and checksums.txt — and did the same across v0.11.0 to v0.14.0. The locally built, trojanized binaries were "designed to steal secrets stored on the disk of any machine that runs it." The CLI stores OVHcloud API credentials in ~/.ovh.conf and reads them from environment variables.

Source builds (go install), the Docker image, and Homebrew (which pinned the original hashes) were not affected. v0.10.0 was clean.

Exposure window

The swapped archives were live for up to 94 minutes, from 12:47 to 14:21 UTC on October 19. The download path does not verify hashes, so anyone who ran the official install script, pulled the archive from the release page, had a CI job fetch it without a pinned hash, or used the CLI's own upgrade command on macOS or Linux (v0.12.0–v0.14.0) could have pulled a backdoored build. A customer's CI job that pins the SHA-256 of the Linux arm64 archive began failing and raised the alarm via a public GitHub issue at 13:50 UTC. OVHcloud deleted the swapped files at 14:21 UTC and published v0.16.0 at 17:16 UTC.

Indicators

Indicators published in the OpenSourceMalware/The Hacker News writeup for the v0.15.0 swap:

Trojanized build module line
  v0.15.1-0.20261013083505-5ead8ef9b43d+dirty
Recorded commit  5ead8ef   (the v0.15.0 tag points to 760fd72)
Build flags      -ldflags="-s -w"

SHA-256, swapped v0.15.0 Linux arm64 archive
  3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb
SHA-256, original v0.15.0 Linux arm64 archive
  5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0

Action checklist

1. Inventory every machine and CI runner that installed or upgraded the OVHcloud CLI, and pin only v0.16.0 going forward.
2. If a host ran v0.11.0–v0.15.0, rotate all OVHcloud API credentials (~/.ovh.conf and env vars) and any other secrets reachable from that disk — SSH keys, cloud tokens, .env files.
3. Compare downloaded archive hashes against v0.16.0's published checksums; the original v0.15.0 hash above is a clean reference.
4. Pin SHA-256 hashes in any pipeline that fetches release archives, so an overwrite breaks the build instead of shipping silently.

Context

OpenSourceMalware linked the uploading account to the GlassWorm campaign — the account had been compromised for over six months, with a scripted history rewrite in early March and a hidden preinstall.js loader decoding to a Solana-memo dead drop. The researchers framed the GlassWorm tie as "our inference"; no October binary has been matched to GlassWorm, so treat the attribution as unconfirmed.

The pattern is the week's recurring one: the registry and the source were fine, but the distribution surface — a GitHub release, an npm maintainer flow — was not. Immutable releases and pinned hashes are the cheap controls that would have turned this from an incident into a failed build.