Trojanized on GitHub, OVHcloud's command-line tool tried to steal your secrets
On October 19, for 94 minutes, trojanized binaries replaced those of the ovhcloud-cli tool. Which versions were hit, who may have installed them, and which secrets to change.
Translated from French by AI. The original French article is the reference version.

On Monday, October 19, in the mid-afternoon, the continuous integration pipeline of a user of OVHcloud's command-line tool failed. Its script compares the checksum of the downloaded Linux archive with a value recorded in advance, and it no longer matched. At 3:50 p.m. (Paris time), the user opened a ticket on GitHub. The release files that had been published weeks earlier had just been replaced.
The alert was justified. That evening on X, Octave Klaba, OVHcloud's chairman, confirmed that the version of the tool distributed at 2:47 p.m. had been compromised by a hacker. The hosting provider blocked it at 4:21 p.m. According to him, versions 0.11.0 through 0.15.0 of the tool, called ovhcloud-cli, are affected, while 0.10.0 and the new 0.16.0 are clean. The added program tried to harvest secrets stored on the machine's disk. Octave Klaba judges it to be of poor quality, but capable of doing its job, according to Next.
How could the files be replaced?
The hacker did not publish a new version. Within existing releases, they replaced the archives for Linux, macOS and Windows, as well as the checksum file. Verifying an archive against that file was therefore useless. Only a checksum recorded before the attack could reveal the substitution. The author of the ticket also notes that the suspicious binary was compiled locally from changes that were never published. It therefore does not come from OVHcloud's usual build pipeline.
According to Octave Klaba, the attacker went through the GitHub account of a developer who had write access. He explains that the option preventing changes to a release already published on GitHub had not been enabled. “The option has been enabled,” he adds, specifying that the build pipelines were not affected and that no other repository is impacted. The site OpenSourceMalware notes that personal repositories belonging to this developer had already been modified in March 2026 with loader code attributed to the GlassWorm group. Its authors acknowledge, however, that they cannot prove it is the same attacker.
Who may have installed the trojanized version?
According to OpenSourceMalware and IT-Connect, those affected are people who installed or updated the tool during this 94-minute window in several ways:
- with the install.sh script or via Homebrew;
- by downloading the archive directly from GitHub;
- through a continuous integration pipeline that fetches these archives.
Installation via go install, building from source code and the Docker image are reportedly not affected. OVHcloud has not said how many downloads took place. The program has not been publicly analyzed, because the files were deleted before they could be archived.
What should you do?
As with the trojanized Rank Math PRO update, the window was short, but the stolen secrets remain valid:
- Check whether the tool was installed or updated on October 19 between 2:47 p.m. and 4:21 p.m. (Paris time), on a workstation or in a continuous integration pipeline.
- If so, change your OVHcloud API credentials right away (
.ovh.conffile or environment variables), as well as your SSH keys, your tokens for other cloud services or package registries, your kubeconfig files and.envfiles. - Upgrade to version 0.16.0, published that same evening as an immutable release.
- Known checksum of the trojanized archive (v0.15.0, Linux arm64):
3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb. - In your continuous integration pipelines, pin the checksum of downloaded tools: that is what made it possible to detect the attack.
OVHcloud has promised a detailed analysis of the incident in the coming days. It will need to explain how the developer's credentials were stolen.
Method: AI-assisted monitoring, verified sources, article reviewed and approved by Frédéric LENQUETTE. Our editorial policy.
Share this article