- A hijacked contributor account replaced download files on five OVHcloud CLI releases on October 19 for up to 94 minutes, and OVHcloud says the files were built to steal secrets.
- GitHub's release immutability setting was off, so old releases could be edited. The checksum file was swapped too, so hashes matched the bad binaries.
- Check who installed the tool in that window and rotate their secrets. Also check whether your own releases are immutable and where your checksums are stored.
A download link is a promise about a place, not a file
A version number is usually read as a fixed thing. Version 0.15.0 of a tool should be the same file today as it was last month. The OVHcloud incident shows why that belief needs a check behind it.
The lesson here is simple. A release page is a folder, not a seal. Unless the platform locks it, whoever holds write access can change what sits behind an old link, and the link itself does not change.
What happened
On Monday, October 19, someone took over a contributor's GitHub account and used it to overwrite downloads on five already-published versions of OVHcloud's command-line tool. The Hacker News reports that OVHcloud describes the substitute files as a build meant to harvest secrets from the disk of any machine that ran it.
The bad files sat on GitHub from 12:47 to 14:21 UTC, so for up to 94 minutes. Only downloads made during that span could have delivered a swapped file. The install route involved did not verify a hash. Affected platforms were macOS, Linux (x86_64 and arm64) and Windows x86_64.
OVHcloud names versions 0.11.0 through 0.15.0 as compromised and 0.10.0 as clean. These five went out between April 14 and September 16. The Hacker News adds that a copy fetched before 12:47 UTC on Monday and left alone since is the genuine file.
How the swap worked
According to the report, the attacker did not touch OVHcloud's source code, its release tag or its build pipeline. The malicious build was an ordinary compile of a newer commit, uploaded onto old releases.
For v0.15.0, six files were replaced. They were the macOS, Linux and Windows archives plus checksums.txt, the file listing each archive's expected fingerprint. Releases v0.11.0 through v0.14.0 show the same gap, with those six files no longer attached.
That detail matters. A checksum stored beside the download proves the file matches the list. It does not prove who wrote the list. Anyone who can replace one can replace both, and the hashes then agree with the bad binaries.
The setting that was off
On GitHub, anyone with write access can delete a release's files and upload new ones under the same names. The download address stays the same. Release immutability locks a release's files and tag. It has been generally available since October 2025. It protects only releases created after it is switched on.
In a late Monday post quoted by Next, OVHcloud founder Octave Klaba blamed the switched-off option. Without it, a user with the right permissions could edit existing releases directly on GitHub. No check from the company's CI/CD pipeline, its automated build system, stood in the way. The option is now on, and OVHcloud issued a clean v0.16.0 that evening, locked as immutable.
What is still unknown
The company has not disclosed what the malicious build reads, where it sends the data, or how many copies were downloaded. The Hacker News says no swapped archive has been analyzed in public. OVHcloud says a full postmortem will follow.
A customer noticed the swap and reported it in a GitHub issue. According to The Hacker News, the customer inspected the new v0.15.0 Linux arm64 binary with a Go tool command, go version -m. That command reads a file's embedded build record without running the file.
A caution applies to the advice that followed. Some people suggested that any build marked +dirty is malicious. The Hacker News found OVHcloud's own clean v0.16.0 carries that marker too.
Who carries the cost
The person at risk is the engineer who ran a routine install on a laptop or build server in that window. Klaba advises changing every secret stored on the disk. The tool's documentation says it keeps API credentials in a file called ~/.ovh.conf and can read them from environment variables. The Hacker News notes the advice reaches beyond those files.
Rotating secrets across many machines is slow work. The cost lands on whoever has to find out which machines pulled the tool in that window.
Questions to put to your team
First, did anyone install or update the OVHcloud CLI on Monday between 12:47 and 14:21 UTC? If so, treat that machine's stored secrets as exposed and rotate them.
Second, which of our own repositories publish downloads, and is release immutability on? It protects only releases made after it is enabled, so older releases need a separate look.
Third, where do our install scripts get their checksums? A hash fetched from the same place as the file adds little. Ask for hashes or signatures held somewhere an account takeover cannot reach.
Fourth, how many people can write to our release pages, and is each account protected against takeover?
A version number only means something if the platform will not let it change. Check that yours will.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OVHcloud.
