A 94-minute window, caught by accident
On October 19, attackers using a hijacked contributor's GitHub account replaced the downloadable archive files on five already-published OVHcloud CLI releases, spanning version 0.11.0 through 0.15.0, originally published between April 14 and September 16. The swap covered six files per release: the macOS, Linux, and Windows x86_64 and arm64 archives, plus the checksums.txt file, meaning the published hashes were rewritten to match the malicious binaries rather than the legitimate ones. Anyone verifying the download against the official checksum file would have seen a match, because the attackers controlled both sides of that check. The malicious files were live from 12:47 to 14:21 UTC, a window of up to 94 minutes.
The discovery had nothing to do with OVHcloud's own monitoring. A customer had pinned the SHA-256 hash of the Linux arm64 archive inside their own continuous integration pipeline, a practice meant to guard against exactly this kind of tampering, and their CI job began failing when the hash no longer matched. The customer inspected the downloaded binary using go version -m, found build metadata inconsistent with a legitimate release, including a pseudo-version string referencing a different commit than the one tagged in the repository, and filed a public GitHub issue at 13:50 UTC. OVHcloud deleted the swapped files roughly thirty minutes later, at 14:21 UTC.
No private channel to report an active attack
The customer who caught this had no choice but to disclose a live, ongoing secret-stealing supply chain attack in a public GitHub issue, because OVHcloud's CLI repository had no private vulnerability reporting channel configured. That is a basic piece of open-source security hygiene, standard practice for any project with meaningful adoption, and its absence here meant the vulnerability report doubled as a public alert to every other user of the affected releases, for better or worse, before OVHcloud had even removed the malicious files. In this case transparency moved fast enough that the exposure window stayed short, but the sequencing was accidental, not designed.
The affected releases were exposed only through specific installation paths: the official install script, manual archive downloads, unpinned continuous integration jobs, or the CLI's own upgrade command on macOS and Linux. Users who installed via Homebrew were protected because Homebrew had pinned the original hashes independently. Users who built from source via go install were unaffected because the underlying v0.15.0 git tag itself was never altered, only the pre-built binary archives attached to the GitHub release. The Docker image was untouched because its latest tag had last been pushed on September 21, before the compromise window. This is a reminder that supply chain exposure in a single tool can vary dramatically by installation method, and most security teams do not track which method each of their systems actually used.
The root cause is a setting most teams assume is already on
OVHcloud founder Octave Klaba explained in a follow-up post that the underlying cause was straightforward: release immutability was not enabled on the repository, meaning a user with sufficient permissions could directly modify the files attached to an already-published GitHub release without going through any CI or CD pipeline check. GitHub has supported immutable releases as a protection specifically against this attack pattern, and its absence here is what let a single compromised account alter six files across five historical releases without triggering any automated gate. OVHcloud has since enabled the setting, and Klaba confirmed the build pipelines themselves were not compromised, only the already-published release artifacts.
This matters beyond OVHcloud because the same gap likely exists in a large number of open-source and internal release processes that CTOs assume are protected by CI without ever confirming that published release assets specifically cannot be altered after the fact. A pipeline can be perfectly secure and still leave this door open, because the vulnerability sits in what happens to artifacts after the pipeline finishes, not in the pipeline itself. Any engineering organization that distributes CLI tools, SDKs, or binaries through GitHub releases should verify today whether immutable releases are enabled, rather than assuming a secure build process covers post-publication tampering.
Attribution is a guess, and the researchers say so
The security research group OpenSourceMalware linked the hijacked GitHub account to the GlassWorm campaign, a known supply chain threat actor, based on the observation that four of the account's personal repositories had been force-pushed with a loader back in March. The researchers were explicit that connecting that March activity to the October OVHcloud binary swap is their inference, not a confirmed match, because no copy of the malicious binary from this specific incident was preserved for comparison. That caveat matters because attribution claims in supply chain attacks often get repeated as fact once a plausible-sounding link is published, and here the researchers themselves flagged the gap in their own evidence.
What remains unconfirmed and arguably more operationally important than attribution is what the malicious binary actually did once installed: which specific secrets it read from disk, where it sent stolen data, and how many machines actually downloaded and ran it during the 94-minute window. OVHcloud has not published those details and has promised a fuller postmortem. Until that arrives, any organization that may have pulled an affected version through an exposed installation path during the window should treat the exposure as confirmed and the specific damage as unknown, which is precisely the posture Klaba's advice reflects.
What this means for your own release pipeline
If any system in your environment installed or updated the OVHcloud CLI via script, manual download, unpinned CI, or the upgrade command on macOS or Linux at any point on October 19, Klaba's advice stands: treat every secret readable from that machine's disk as exposed and rotate it from a separate, uncompromised machine, then reinstall v0.16.0, the first release published as immutable with a signed tag. Verify any future download using gh release verify-asset rather than trusting a checksum file that, as this incident showed, an attacker with release-write access can simply rewrite to match their own payload.
The broader roadmap item is to audit whether your own organization's published release artifacts, for any internal tool, SDK, or CLI distributed via GitHub, Homebrew, or a package registry, are protected by immutability or an equivalent control, rather than relying on the integrity of the build pipeline alone. This incident was caught by one customer's unusually disciplined CI hash pinning, a practice most teams do not follow precisely because they assume the vendor's release process already guarantees it. That assumption is the gap this incident exposes, and it is worth testing against your own release process before a similarly compromised account finds it for you.
