Key points
- An attacker replaced download files for five OVHcloud CLI releases on GitHub using a compromised contributor account.
- The malicious binaries were designed to steal secrets stored on the local disk of machines running the software.
- OVHcloud confirmed the swap lasted 94 minutes before detection and blocked the files.
The attacker gained access to a trusted distribution channel by hijacking a developer account, allowing them to replace legitimate software archives with malicious code. This weakness in release file immutability enabled a supply-chain intrusion, granting the adversary the ability to deliver secret-stealing malware directly to users who trusted the official repository. The attack served as an initial access vector, bypassing user scrutiny by appearing as a routine update.
In plain English
On 19 October, an intruder used a stolen GitHub account belonging to an OVHcloud contributor to overwrite the download files for five versions of the company’s command-line interface tool. According to The Hacker News, the replacement files contained a program designed to extract secrets saved on the user’s hard drive. The malicious archives remained live on the platform for 94 minutes, affecting installations on macOS, Linux and Windows systems.
The background
OVHcloud confirmed that versions 0.11.0 through 0.15.0 were compromised, while version 0.10.0 remained clean. The cloud provider stated that the source code and build pipeline were not touched; the attacker simply uploaded a malicious build to existing release pages. OVHcloud CEO Octave Klaba noted that the malware was poorly written but functional. The incident was reported by a customer who noticed the changes, as the repository lacked a private vulnerability reporting channel, according to Cyber Security News.
What changes now
OVHcloud removed the tampered archives and published version 0.16.0 as an immutable release, preventing future file swaps on that specific version. Users who installed the tool before 12:47 UTC on 19 October and did not update during the incident window retain the original, safe files. The provider has not explained how the developer account was initially compromised, but initial checks found no other affected repositories within the organisation.
The attacker's path
Teams usually encounter this class of threat when trusted supply-chain elements are bypassed. The weakness lies in the assumption that download links remain static and untampered. This stage of an intrusion serves as initial access, leveraging user trust in official channels. Check whether your download mechanisms verify cryptographic signatures. Verify that release assets cannot be overwritten after publication. Ensure that installation scripts do not blindly fetch binaries without validating their integrity against a known-good hash. Monitor for unexpected changes in binary characteristics during routine updates.
What to do and how to stay safe: OVHcloud
- Check if you installed OVHcloud CLI versions 0.11.0 to 0.15.0 between 12:47 and 14:21 UTC on 19 October.
- Verify the integrity of your current installation by comparing its hash against the official immutable release.
- Monitor systems for unusual outbound network traffic that may indicate secret exfiltration.
- Once the vendor provides an update, move to the latest immutable release version immediately.
Step-by-step guide: Phishing vs Spam: How to Tell the Difference and Stop Threats
General security guidance from the RedTeam Log newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which OVHcloud CLI versions were affected by the tampering?
Versions 0.11.0, 0.12.0, 0.13.0, 0.14.0 and 0.15.0 were compromised.
How long were the malicious files available for download?
The swapped files were live for 94 minutes, from 12:47 to 14:21 UTC.
Was the OVHcloud source code modified by the attacker?
No, the source code and build pipeline were not touched; only release files were replaced.
