OVHcloud CLI: release binaries of already-published versions were replaced on 2026-10-19 with a build that steals secrets from disk, uploaded through a developer's GitHub account
OVHcloud CLI release binaries carried a secret-stealing build for about 90 minutes; a pinned hash caught it
Defender actions
- Find every workstation, build agent and container image build that installed or updated the OVHcloud CLI from a release asset (install script, Homebrew cask, direct download or a CI step fetching the release tarball) between 12:47 and 14:21 UTC on 2026-10-19, and rotate every secret readable on each of those hosts before installing v0.16.0 or later.
Analysis
OVHcloud's founder says a hacker used the GitHub account of one of its developers to add to the official command-line tool's releases a binary whose job is to retrieve secrets from the disk, that versions v0.11.0 to v0.15.0 are compromised, and that v0.10.0 and v0.16.0 are clean (Octave Klaba, 2026-10-19). A user whose CI pins a SHA-256 reported on GitHub that the assets of v0.13.0 to v0.15.0 were replaced between about 12:47 and 13:12 UTC, weeks after publication, by an uploader who is not a public member of the ovh organisation, with a local build of a later commit that has uncommitted changes and no release version flag, while the v0.15.0 tag and the Go module proxy still point at the original commit (GitHub issue #300, 2026-10-19). An OVHcloud maintainer replied that all the binaries involved were deleted at 16:21 (GMT+2) and that v0.16.0, with a signed tag, is an immutable release (GitHub issue #300, 2026-10-19). OpenSourceMalware, working from GitHub's server-side records, says no tag was pushed and no release workflow ran, ties the same account's earlier force-pushes carrying a hidden loader (from 2026-03-05) to the GlassWorm campaign while saying that whether the same actor did both is its inference, notes that the project's release tooling replaces existing assets as normal behaviour, and says it has not analysed the payload because the files were deleted before anyone archived them (OpenSourceMalware, 2026-10-19). How the account was taken over, whether any secret was stolen and the actor are not public.
Triage: a replaced asset alone is not proof, since the project's release tooling replaces assets routinely; the discriminators are an uploader who is not the original publisher, a modified-tree build without the release version, and a digest that changed without a version bump (OpenSourceMalware, 2026-10-19; GitHub issue #300, 2026-10-19).
Cited evidence
The release assets of v0.13.0, v0.14.0 and v0.15.0 were replaced today
All binaries involved have been deleted at 16:21 GMT+2.
This release is immutable, so the assets attached to it can be trusted.
The compromised versions are v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0. (translated from French)
The hacker used the GitHub account of one of the developers and added a binary whose job is to retrieve the secrets on the disk. (translated from French)
If you are concerned, please change all the secrets on your disk. (translated from French)
No tag was pushed and no GitHub Actions workflow ran.
Whether the same actor did both is our inference
OVHcloud deleted the replaced binaries before anyone archived them, so we have not analyzed the payload
Sources3
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.