An attacker who took over the GitHub account of an OVHcloud contributor replaced the download archives on five existing releases of the OVHcloud CLI with a build designed to steal secrets from disk. The tampered files were live for about 94 minutes on Monday before the company blocked them, and OVHcloud has told affected users to change every secret stored on their machines.
Five OVHcloud CLI Releases Replaced With a Secret-Stealing Build
The attacker modified releases v0.11.0 through v0.15.0 of the OVHcloud CLI. Version v0.10.0 and the new v0.16.0 are clean. The tampered files went live at 12:47 UTC on Monday and were blocked at 14:21 UTC, a window of roughly 94 minutes. OVHcloud CEO Octave Klaba quoted the same window as 14:47 to 16:21 Paris time.
A customer reported the tampering, reportedly after a hash check failed. The customer posted the output of the go version -m command, which shows build information, in a GitHub issue.
Which Platforms Received the Malicious Archives
Only the most common platforms were replaced: macOS on x86_64 and arm64, Linux on x86_64 and arm64, and Windows on x86_64. The attacker also swapped the checksums.txt file so the published hashes matched the malicious archives. Linux i386, Windows i386 and arm64, and WebAssembly builds were untouched.
Root Cause: GitHub Release Immutability Was Not Enabled
The malware was built locally and uploaded by hand. The project’s source code, release tags and CI/CD pipelines were not modified. According to the reporting on the incident, the root cause was that GitHub’s release-immutability option was not enabled, which let a privileged account alter existing releases after publication. OVHcloud has since enabled the option and published v0.16.0 as an immutable release, and it deleted the tampered archives.
Klaba described the binary as “poor quality” but warned that it “can go all the way,” and he urged affected users to change all secrets on disk. Anyone who installed or updated the CLI on an affected platform during the window may have had cloud and developer credentials harvested.
The incident required only one thing: an account with permission to modify existing releases. The attacker did not need to alter the repository’s source code, its tags or its build pipelines, which is why those parts of the project stayed clean. The tampered archives and the matching checksums.txt were uploaded by hand, so the project’s automated release process never produced them.
The GitHub release-immutability option that OVHcloud has now enabled stops existing releases from being changed after publication. Its absence is what allowed five separate versions to be rewritten from a single compromised contributor account. The choice of platforms is also notable: the attacker replaced the five most widely used builds, covering macOS, Linux and Windows on mainstream processors, and left niche builds alone, which would have reached the largest number of users while altering the fewest files.
Possible Link to the GlassWorm Actors
Outside researchers have connected the attack to a known malware operation, though OVHcloud itself has not drawn that link.
What OpenSourceMalware Found
Analysts at OpenSourceMalware tie the attack to the actors behind GlassWorm, pointing to infrastructure that includes a payload lookup on the Solana blockchain. They also say the contributor account appeared to have been compromised since at least March 2026. The researchers note that attribution to the same actor is an inference rather than a confirmed finding.
OVHcloud has not mentioned GlassWorm in its statements. The GlassWorm botnet was disrupted in May 2026 by CrowdStrike, Google and Shadowserver, so a link would suggest the operators have continued to work despite that action.
Timeline and Response
The sequence ran quickly. The tampered files appeared at 12:47 UTC on Monday and were blocked at 14:21 UTC. By Monday evening OVHcloud had published a clean, immutable v0.16.0. Coverage and attribution analysis followed on Tuesday and Wednesday.
OVHcloud has told users to remove the tool, clean up their systems and rotate secrets. The long dwell time of the account compromise, if the March 2026 estimate is accurate, means the attacker held access for roughly seven months before using it. That detail raises the question of what else the account could reach in that period, a point the available reporting does not answer.
