On October 19, an attacker used the hijacked GitHub account of a contributor to replace the download archives on five existing releases of OVHcloud's official command-line tool, ovh/ovhcloud-cli. The tampered releases are v0.11.0 through v0.15.0. In posts on X reported by BleepingComputer, OVHcloud CEO Octave Klaba said the malicious builds were meant to "retrieve secrets from the disk," and that v0.10.0 and the newly published v0.16.0 are clean.
According to The Hacker News, the malicious files were available from 12:47 to 14:21 UTC, up to 94 minutes. BleepingComputer, citing Klaba, gave the times as 14:47 and 16:21; OVHcloud's statements use Paris time (UTC+2), so these match the 12:47–14:21 UTC window.
What was changed
The Hacker News reported that the attacker did not compromise the project's source code, tags or build pipeline. Instead, the files attached to already-published releases were swapped. On v0.15.0, six files were replaced: the macOS archives for x86_64 and arm64, the Linux archives for x86_64 and arm64, the Windows x86_64 archive, and checksums.txt. Rewriting the checksum file made the published hashes match the malicious archives. The Linux i386, Windows i386 and arm64, and WebAssembly builds were left alone. The Hacker News said the five releases had originally been published between April 14 and September 16.
OpenSourceMalware, which analyzed the incident, said the uploads went through the contributor's account using the GitHub Releases API, between roughly 12:47 and 13:12 UTC according to the reporter's capture in issue #300, in a cadence that "looks like a script," most likely a loop that deleted each asset and uploaded a replacement. The replacement binary was not produced by the project's normal GoReleaser process. It was a plain go build of commit 5ead8ef, which is newer than the v0.15.0 tag, and it was marked as built from a checkout with uncommitted changes (vcs.modified=true), though The Hacker News notes OVHcloud's clean v0.16.0 build shows the same flag. No tag was pushed and the release workflow did not run.
Klaba said OVHcloud's CI/CD pipelines, including unit tests, functional tests and CVE detection, were not affected, according to BleepingComputer. OpenSourceMalware lists initial access to the account as an open question, and The Hacker News reported that OVHcloud has promised a detailed postmortem.
Why it worked, and how it was caught
Klaba said GitHub's release immutability setting was disabled on the repository, which allowed a sufficiently privileged account to modify existing releases without passing CI/CD checks. As The Hacker News explained, without that setting anyone with write access to a repository can delete the files attached to a release and upload new ones with the same names.
OpenSourceMalware listed several other weaknesses: the replace_existing_artifacts: true setting in the GoReleaser configuration, releases published under personal accounts, a peripheral contributor holding write access, a long-lived personal access token in the release workflow, no binary provenance or attestations before v0.16.0, installers that trusted the release URL without verifying checksums, and no private vulnerability reporting channel.
A customer's CI job, which pinned the SHA-256 hash of the Linux arm64 archive, failed when the hash stopped matching. Because there was no private reporting channel, the customer filed public GitHub issue #300, at 13:50 UTC according to OpenSourceMalware's timeline, The Hacker News reported. OVHcloud deleted the swapped files at 14:21 UTC and at 17:16 UTC published v0.16.0 as an immutable release with an attestation. The company has since enabled release immutability and considers the incident resolved, according to BleepingComputer.
Who was exposed
According to The Hacker News, the paths that could have delivered a malicious build during the window were:
- the project's official install script, which "has never checked a hash";
- direct downloads of an archive from an affected release page;
- CI jobs that fetched release archives without a pinned hash;
- the CLI's built-in upgrade command, run from v0.12.0 through v0.14.0 on macOS or Linux where the CLI had been installed by script or by hand.
Builds from source and the Docker image were not affected, according to both The Hacker News and BleepingComputer. The Hacker News added that go install users were not exposed and that the Docker image's latest tag was last pushed on September 21 and had not been rebuilt.
The sources differ on Homebrew. The Hacker News reported that Homebrew users were not exposed because the cask pinned the original SHA-256 of each archive, so a mismatched download would have been refused. OpenSourceMalware's write-up, however, lists brew install and brew upgrade among the paths through which users are potentially affected.
A possible GlassWorm connection
OpenSourceMalware found that the same contributor account had been misused months before the release swap. On March 5 and 6, 2026, four of the account's personal repositories were amended and force-pushed with a loader hidden in Unicode variation-selector characters; three added it as a preinstall.js file and the fourth had the same decoder inlined. The loader uses a memo attached to a Solana wallet as a dead drop for its next stage, and the researchers describe that wallet as a known GlassWorm indicator. BleepingComputer, reporting on the findings, said the account had been compromised for more than half a year.
The researchers say that whether the same actor carried out both the March and October activity is "our inference." No copy of the October binary was preserved, The Hacker News reported, so it has not been tied to GlassWorm directly, and BleepingComputer noted the researchers did not analyze the payload delivered through the trojanized CLI.
What It Means for Defenders
- Check for exposure. Search shell history, CI logs and package records for any install or upgrade of the OVHcloud CLI during the October 19 window through the paths listed above, and include Homebrew installs given OpenSourceMalware's listing.
- Rotate secrets from a different machine. Klaba urged affected users to clean their systems and revoke all secrets. OpenSourceMalware's list covers OVHcloud API and consumer keys,
~/.ovh.conf, cloud provider credentials, SSH keys, tokens in.npmrc,.pypircand.netrc, Kubernetes configs, and secrets in.envfiles. - Reinstall and verify. Remove the binary, install v0.16.0, and check downloaded archives with
gh release verify-asset, as The Hacker News advises. - Pin hashes in CI. Apply SHA-256 pinning to every third-party binary your pipelines download.
- Audit your own releases. If you publish binaries on GitHub, turn on release immutability and review which accounts and long-lived tokens can overwrite release assets.
