TL;DR
On October 19, 2026, an attacker replaced official OVHcloud CLI release files on GitHub with a build that steals secrets from disk. A customer spotted the OVHcloud CLI attack when a checksum check failed in their pipeline. OVHcloud says it blocked the malicious release within 94 minutes.
Delivery
This supply chain attack did not involve a new version. Instead, they swapped the files inside older releases that had shipped weeks earlier. According to the customer’s GitHub issue, the changes happened between about 12:47 and 13:12 UTC.
The customer’s build system pins the SHA-256 hash of one download. When that hash changed, the build failed. Further checks showed the new binary was a local build of a later commit with uncommitted changes. It also lacked the version flag that the real release pipeline adds.
Infection chain
Users who installed an affected release ran the swapped binary as if it were the normal CLI. The Stack reports that versions v0.11.0 through v0.15.0 are compromised. However, v0.10.0 and the upcoming v0.16.0 are clean.
In a post on X, Klaba explained the entry point. “The hacker used the GitHub account of one of the developers and added a binary whose job is to retrieve secrets from the disk,” he wrote. He added that “no other repo is affected.”
Command-and-control and data exfiltration
OVHcloud has not yet shared where the OVHcloud CLI attack binary sends stolen data. Klaba described its quality as “poor but it can go all the way.” The company says it is still analyzing the binary and will publish more details.
Attribution remains unconfirmed. Klaba has not named the attacker or explained how they gained access to the developer’s account.
Defense and detection guidance
Klaba urged affected users to act now: “If you are affected, please change all the secrets on your disk.” Additionally, The Stack’s report on the OVHcloud CLI repo compromise noted that releases should come only from a locked-down, approved pipeline. Key steps include:
- Check whether you installed v0.11.0 to v0.15.0 from GitHub releases.
- Rotate API keys, cloud credentials, and SSH keys stored on affected machines.
- Pin checksums for third-party binaries, as this customer did.
- Build Go tools from the module proxy instead of prebuilt release files.
- Treat release assets as immutable, and enforce MFA on developer accounts.
Overall, this OVHcloud CLI attack shows how one hijacked account can poison a trusted tool. In this case, a single pinned checksum caught it.
Support Our Threat Intelligence
Find our threat intelligence and malware analysis helpful? Support our work today and unlock a 100% ad-free reading experience!