Attacker swapped OVHcloud CLI archives to steal local secrets in 94-minute GitHub exploit
Attackers replaced archives on five OVHcloud CLI releases with malicious builds, targeting users who installed or updated the tool during a 94-minute window on GitHub.
Key points
- An attacker used a hijacked contributor account to swap download archives on five OVHcloud CLI releases.
- The malicious builds were designed to steal secrets stored on the local disk of any machine running them.
- OVHcloud removed the bad files and published an immutable v0.16.0 release to prevent further tampering.
Attackers gained the ability to execute secret-stealing code on user machines by compromising a trusted software distribution channel. They needed access to a contributor’s GitHub account and the ability to replace existing release assets. This allowed them to inject malicious binaries into the official OVHcloud command-line interface tool, reaching anyone who downloaded or updated the software during the incident window.
In plain English
The attackers did not change the source code or the build pipeline. Instead, they uploaded pre-compiled, malicious program files to five existing software releases on GitHub. These files looked like normal updates but contained code designed to scan the computer’s hard drive for stored passwords and keys. Users who installed the tool during the attack window received these bad files instead of the legitimate software.
The background
According to The Hacker News, the incident occurred on Monday, October 19. The malicious files were live on GitHub for 94 minutes, from 12:47 to 14:21 UTC. An attacker used a hijacked contributor account to replace archives on versions v0.11.0 through v0.15.0. OVHcloud CEO Octave Klaba confirmed v0.10.0 was clean and announced a safe, immutable v0.16.0 release. Cyber Security News reported that a customer spotted the changes and alerted the provider.
What changes now
OVHcloud deleted the swapped archives and published v0.16.0 as an immutable release, meaning GitHub will not allow anyone to change its files. The source code, release tags, and build pipeline were not touched. The bad build was a plain Go build of a later commit, uploaded to releases published between April and September. Linux i386, Windows i386, Windows arm64, and WebAssembly builds were left alone on every release.
What made it possible
This incident highlights the risk of trusting release assets without cryptographic verification. When download scripts or update commands fetch binaries from a repository without checking a pinned hash, they assume the server is always honest. If an attacker compromises an account with permission to upload files, they can replace legitimate software with malicious versions. Teams usually mitigate this by verifying checksums against a known-good source or using signed artifacts.
What to do and how to stay safe: OVHcloud
- Verify the SHA-256 hash of your installed CLI binary against the official clean release provided by the vendor.
- Ensure your installation scripts or CI pipelines pin specific versions and verify checksums before executing downloaded files.
- Monitor system logs for unusual disk access patterns or outbound connections from the CLI process.
- Switch to building the tool from source code or using a module proxy if you require continuous updates.
General security guidance from the RedTeam Monitor newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which OVHcloud CLI versions were compromised?
Versions v0.11.0, v0.12.0, v0.13.0, v0.14.0, and v0.15.0 were compromised; v0.10.0 is clean.
How long were the malicious files available?
The files were live on GitHub for 94 minutes, from 12:47 to 14:21 UTC on October 19.
Did the attackers change the source code?
No, the source code, release tags, and build pipeline were not touched; only the uploaded binaries were replaced.
